El código del juego no cambia, pero el servidor se vuelve más lento después de actualizar el SO, el kernel, los drivers o el firmware. Las actualizaciones pueden cambiar valores predeterminados, el planificador, las mitigaciones de vulnerabilidades de la CPU (mitigations) o el comportamiento de los drivers.
Por qué Un parche de seguridad periódico o una imagen de servidor nueva cambia el kernel, los drivers o el firmware → Efecto Cambian los valores predeterminados o el planificador, o se activan nuevas mitigaciones: el mismo trabajo consume más tiempo de CPU y cambia el orden en que los hilos reciben CPU → En pantalla Un servidor que iba bien va siempre un poco más lento desde el día de la actualización: input lag y, cuando se junta mucha gente, tirones y cámara lenta
Responsable principal Infraestructura de servidores (Equipo de infraestructura)
Tareas (Equipo de infraestructura)
Aplicar las actualizaciones primero en algunos servidores y comparar el tiempo de tick, la latencia y el uso de CPU con la versión anterior antes de extenderlas, desplegarlas en un día distinto al de los parches del juego, registrar antes y después de actualizar las versiones del kernel, los drivers y el firmware y los valores sysctl principales, arrancar con el kernel anterior para comprobarlo si surge un problema, decidir si se desactivan las mitigaciones (mitigations=off) sopesando el riesgo de seguridad.
Cifras de referencia
Al cambiar de versión del kernel cambia también el comportamiento predeterminado. Por ejemplo, Linux empezó a pasar del planificador CFS a EEVDF a partir de la 6.6, y el valor predeterminado del límite de la cola de conexiones pendientes (somaxconn) pasó de 128 a 4,096 desde la 5.4. Las mitigaciones de vulnerabilidades de la CPU añaden trabajo, como vaciar búferes internos de la CPU al volver del kernel al programa (al terminar cada llamada al sistema) y en los cambios de contexto y de máquina virtual, así que afectan más a los servidores de red que hacen una llamada al sistema por paquete. Para cerrar del todo algunas vulnerabilidades hay que desactivar SMT (la función que hace que un núcleo funcione como dos hilos), y sin SMT el rendimiento puede caer mucho según la carga de trabajo. El parámetro del kernel mitigations=off desactiva todas estas mitigaciones y recupera el rendimiento, pero deja el sistema expuesto a las vulnerabilidades.
En el gráfico
Salto en escalón · Tiempo de tick del servidor, uso de CPU, latencia con la misma carga
Dónde mirar
Historial de actualizaciones del gestor de paquetes y hora del reinicio, versión del kernel con uname -r y datos del driver de la NIC con ethtool -i, cruzados con la hora en que subió la latencia. Comparar con mpstat y pidstat un servidor actualizado y otro sin actualizar con la misma carga, y también el estado de las mitigaciones en /sys/devices/system/cpu/vulnerabilities/
Se confirma si
La latencia y el uso de CPU suben un escalón desde el reinicio tras la actualización y se quedan ahí, y con la misma carga solo están altos los servidores actualizados. Al arrancar con el kernel o el driver anterior, vuelven a la normalidad
Se descarta si
Si los servidores actualizados y los no actualizados van igual de lentos con la misma carga, no es esta causa. Si el mismo día también se desplegó un parche del juego y cambiaron el número o el tamaño de los paquetes por jugador: “Cambio del patrón de tráfico tras un parche”
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
El estado de las mitigaciones se consulta en los archivos de /sys/devices/system/cpu/vulnerabilities/. El valor predeterminado (mitigations=auto) aplica las mitigaciones con SMT activado, pero con auto,nosmt se desactiva SMT en las CPU vulnerables, así que, tras actualizar el kernel, el número de núcleos lógicos puede quedar a la mitad. Si se actualiza el SO el mismo día que sale un parche del juego, cuesta distinguir la causa, así que conviene desplegarlos por separado.
Fuentes
The kernel’s command-line parametersLinux kernel mitigations=: off desactiva todas las mitigaciones de vulnerabilidades de la CPU y mejora el rendimiento, pero deja el sistema expuesto; el predeterminado, auto, aplica las mitigaciones con SMT activado; auto,nosmt desactiva SMT si hace falta
MDS - Microarchitectural Data SamplingLinux kernel Las mitigaciones vacían búferes de la CPU al volver del kernel al espacio de usuario y al entrar en una máquina virtual; el estado de las vulnerabilidades y mitigaciones se consulta en los archivos de /sys/devices/system/cpu/vulnerabilities/; en muchas CPU, cerrar del todo la vulnerabilidad exige desactivar SMT, y sin SMT el impacto en el rendimiento es grande según la carga de trabajo
Spectre Side ChannelsLinux kernel Como mitigación, se vacían los búferes de predicción de saltos en los cambios de contexto y de máquina virtual, y las mitigaciones más fuertes añaden sobrecarga a todos los programas
EEVDF SchedulerLinux kernel Linux empezó a pasar del planificador CFS a EEVDF a partir de la 6.6
listen(2) — Linux manual pageLinux man-pages El valor predeterminado de somaxconn pasó de 128 a 4,096 desde Linux 5.4