Los núcleos de CPU inactivos entran en estados de ahorro de energía profundos (C-states) y bajan su frecuencia para ahorrar electricidad. Cuando llega un paquete o vence un temporizador, despertar y subir la frecuencia lleva tiempo, y eso añade latencia al procesar paquetes pequeños.
Por qué La política de escalado de frecuencia del SO (governor) o la configuración de energía de la BIOS permiten C-states profundos y frecuencias bajas → Efecto Cada vez que un núcleo inactivo sale de un estado de ahorro profundo se retrasa hasta varios cientos de µs, y si la frecuencia se queda fijada baja, el propio cálculo del tick se vuelve lento → En pantalla Casi siempre es imperceptible, pero con muchas llamadas entre servidores se acumula y aparece input lag, curiosamente cuando hay poca gente. Si la frecuencia se queda fijada baja, el tick se retrasa cuando se junta mucha gente: cámara lenta
Responsable principal Infraestructura de servidores (Equipo de infraestructura)
Tareas (Equipo de infraestructura)
Poner la configuración de energía de la BIOS en modo rendimiento y el governor del SO en performance (scaling_governor de cpufreq), limitar los C-states profundos en los servidores sensibles a la latencia (perfil latency-performance de tuned, /dev/cpu_dma_latency de PM QoS, parámetro del kernel intel_idle.max_cstate), comparar después del cambio el tiempo de ida y vuelta dentro del centro de datos, el jitter del tiempo de tick y el consumo eléctrico.
Cifras de referencia
Según la tabla del driver intel_idle de Linux 6.12, en las CPU de servidor de Intel el C1 (poco profundo) tarda 1–2 µs en despertar, y el C6 (profundo), de 133 µs (Skylake-SP) a 290 µs (Sapphire Rapids). Cada vez es poco, pero si una solicitud pasa por varios servidores, se acumula. El kernel elige estados más profundos cuanto más largo prevé el tiempo inactivo, así que ocurre más a menudo en servidores con poca carga, donde los paquetes llegan espaciados. El governor powersave del cpufreq genérico fija la frecuencia más baja del rango permitido (el algoritmo del mismo nombre de intel_pstate la ajusta según la carga).
En el gráfico
Siempre alto · Tiempo de ida y vuelta dentro del mismo centro de datos, frecuencia de los núcleos
Dónde mirar
Porcentaje de tiempo en cada C-state y frecuencia real por núcleo con cpupower monitor; name, latency (µs que tarda en despertar) y usage de cada state en /sys/devices/system/cpu/cpu0/cpuidle/; scaling_governor de cpufreq y el perfil actual con tuned-adm active
Se confirma si
Con poca carga, los núcleos pasan mucho tiempo en el C-state más profundo o la frecuencia se queda fijada cerca del mínimo, y al pasar al governor performance con C-states poco profundos bajan el tiempo de ida y vuelta y el jitter de las solicitudes pequeñas
Se descarta si
Si al cambiarlo la diferencia es de unas decenas de µs o menos, se puede ignorar esta causa. Si los picos son del orden de ms: “CPU steal (máquinas virtuales)” u otra capa
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
En los servidores bare metal del centro de datos hay que revisar a la vez la configuración de energía de la BIOS (firmware) y la del SO. En la nube, el SO solo puede cambiar los C-states y la frecuencia en algunos tipos de instancia, y en AWS la configuración predeterminada prioriza el máximo rendimiento, así que casi siempre se puede dejar como está. El perfil latency-performance de tuned, de la familia Red Hat, pone el governor en performance y, con PM QoS, limita el uso a C-states poco profundos. Desactivar el ahorro de energía aumenta el consumo eléctrico, así que solo conviene hacerlo en los servidores sensibles a la latencia.
Fuentes
CPU Idle Time ManagementLinux kernel Cada estado de ahorro tiene un tiempo de salida (exit latency) y un tiempo mínimo de permanencia (target residency), y el estado profundo se elige según el tiempo inactivo previsto; latency, usage y time por state en sysfs; limitar los estados profundos con PM QoS (/dev/cpu_dma_latency) e intel_idle.max_cstate
drivers/idle/intel_idle.c (Linux v6.12)Linux kernel Tiempo de salida por C-state en CPU de servidor de Intel: Skylake-SP C1 2 µs, C1E 10 µs, C6 133 µs; Ice Lake C6 170 µs; Sapphire Rapids C1 1 µs, C6 290 µs
CPU Performance ScalingLinux kernel Consultar y cambiar el governor con scaling_governor; performance pide la frecuencia más alta del rango permitido y powersave, la más baja
intel_pstate CPU Performance Scaling DriverLinux kernel El algoritmo powersave de intel_pstate, a diferencia del governor powersave genérico, ajusta la frecuencia según la carga (parecido a schedutil y ondemand)
Chapter 2. Getting started with TuneDRed Hat El perfil latency-performance desactiva las funciones de ahorro de energía, pone el governor en performance y, con PM QoS, limita el uso a C-states poco profundos; consultar el perfil actual con tuned-adm active
Processor state control for Amazon EC2 Linux instancesAWS Solo en algunos tipos de instancia el SO puede controlar los C-states y P-states, y se pueden cambiar para reducir la latencia; la configuración predeterminada es de máximo rendimiento, adecuada para la mayoría de las cargas; Graviton tiene frecuencia fija y el SO no la controla