Núcleo sin cosquillas y eficiencia energética: cómo optimizar su servidor

A Núcleo sin cosquillas reduce los despertares innecesarios de la CPU y, por tanto, disminuye activamente los requisitos energéticos de tu servidor sin perder capacidad de respuesta bajo carga. Le mostraré paso a paso cómo minimizar los Núcleo configurar, leer los valores medidos y planificar las cargas de trabajo de forma que el rendimiento y los costes de electricidad se armonicen notablemente.

Puntos centrales

Los puntos siguientes resumen los pasos y correlaciones más importantes.

• Sin cosquillas Temporizador: interrupciones controladas por demanda en lugar de ticks periódicos
• Energía ahorrar: Mantener los estados C profundos más tiempo, reducir los despertares.
• NO_HZ Opciones: Utilizar CONFIG_NO_HZ_IDLE y CONFIG_NO_HZ_FULL
• programador Ajuste: carga de paquetes, afinidad de interrupciones
• Monitoreo Primero: Medición antes/después para efectos claros

El modo sin cosquillas explicado brevemente

Un Linux clásicoNúcleo despierta cada CPU a intervalos fijos, a menudo de 100 a 1000 veces por segundo. Esto cuesta mucho Energía, aunque no haya ninguna tarea pendiente. El modo Tickless sustituye esta periodicidad por interrupciones de temporizador controladas por demanda. Como resultado, la CPU permanece en estados de sueño profundo durante más tiempo hasta que se produce realmente un evento. Según [1], es precisamente este comportamiento el que aumenta la eficiencia porque se eliminan los despertares innecesarios y se reduce la carga térmica. Yo utilizo Tickless cuando los sistemas ven cargas muy fluctuantes y necesitan cambiar limpiamente entre actividad y reposo.

Por qué Tickless aumenta la eficiencia energética

Si una CPU permanece inactiva, los ticks rígidos utilizados para evitar bajas Estados C y despertaba núcleos todo el tiempo. Esto generaba más Calor residual y obligaba a los ventiladores a funcionar a mayor velocidad. Tickless elimina este despertador permanente y prolonga las fases de inactividad. He observado un menor consumo de energía en modo inactivo y curvas de temperatura más suaves para hosts web y API con cargas de trabajo fluctuantes. En grandes granjas de servidores, los pequeños ahorros por nodo se suman a cantidades de euros notables en la factura de la luz. La plataforma permanece más silenciosa y los picos de carga pueden amortiguarse con mayor fiabilidad.

Modos y opciones del núcleo de un vistazo

Distingo dos enfoques principales: Tickless Idle y Tickless Full. Tickless Idle pausa el periódico mientras no haya tareas pendientes, y reproduce su Fuerza especialmente en las fases de reposo. Tickless Full (NO_HZ_FULL) reduce los ticks de los núcleos seleccionados incluso durante el funcionamiento, lo que puede reducir las latencias y los cambios de contexto. Las distribuciones modernas suelen activar NO_HZ_IDLE por defecto, mientras que NO_HZ_FULL requiere un ajuste específico. Tenga en cuenta que los modos extendidos requieren un ajuste fino de la afinidad de interrupción y el aislamiento para garantizar que la Ventajas no se desvanezca debido a despertares aleatorios.

Modo/Opción	Efecto	Adecuado para	Notas
CONFIG_NO_HZ_IDLE	Suspender ticks en modo inactivo	Carga general del servidor con fases de inactividad	A menudo activo por defecto, bajo Riesgos
CONFIG_NO_HZ_FULL	Minimizar los ticks por núcleo durante el funcionamiento	Baja latencia, HPC, núcleos seleccionados	Aislamiento del núcleo limpio y afinidad IRQ Plan
isolcpus, rcu_nocbs	Núcleos de bajo ruido, menos activaciones de la RCU	Cargas de trabajo en tiempo real	Sólo unos pocos núcleos aíslan, el resto lleva carga del sistema
Kernel ≥ LTS actual	Nuevas vías de ahorro energético, correcciones	Todos los sistemas productivos	Correcciones y aumento de la eficacia según [1] use

Paso a paso: Configurar el kernel y los parámetros de arranque

Empezaré con un inventario de las capacidades del kernel. Puedes reconocer si el kernel soporta tickless por las banderas de configuración:

grep NO_HZ /boot/config-$(uname -r)
grep HIGH_RES_TIMERS /boot/config-$(uname -r)
grep -E 'CPU_IDLE|INTEL_IDLE' /boot/config-$(uname -r)

Para NO_HZ_IDLE, el kernel de distribución suele ser suficiente. Para NO_HZ_FULL, defino específicamente CPUs de mantenimiento que se encargan de las tareas del sistema, IRQs y RCU callbacks. Normalmente, dejo la CPU 0-1 como "housekeeping" y pongo el resto de núcleos en modo DyTick:

# Ejemplo GRUB-CMDLINE (adaptar al hardware):
GRUB_CMDLINE_LINUX="nohz_full=2-15 isolcpus=2-15 rcu_nocbs=2-15 irqaffinity=0-1 nmi_watchdog=0"

Importante: Al menos un núcleo debe permanecer en casa, de lo contrario existe el riesgo de que la RCU se atasque. Tras actualizar la configuración de GRUB y reiniciar, compruebo la configuración activa:

cat /sys/devices/system/cpu/nohz_full # lista las CPUs NO_HZ_FULL
cat /sys/devices/system/cpu/isolated # lista las CPUs aisladas
cat /proc/cmdline # verifica los parámetros de arranque

También activo los temporizadores de alta resolución y los controladores específicos de reposo (por ejemplo, intel_idle). Ambos mejoran la precisión de los temporizadores y la profundidad de los estados de reposo. Si usas irqbalance, configura los núcleos bloqueados para que la afinidad no migre a CPUs aisladas:

# Ejemplo: IRQBALANCE_BANNED_CPUS en /etc/irqbalance/irqbalance.env
IRQBALANCE_BANNED_CPUS=0x0003 # CPUs 0-1 permitidas, resto bloqueadas (formato de máscara por sistema)

Luego verifico que los ticks están efectivamente ausentes mirando los siguientes despertares por CPU:

sudo cat /proc/timer_list | grep -A2 'next event' | sed -n '1,60p'

En las fases tranquilas, los próximos eventos deben estar claramente en el futuro o completamente ausentes si no hay temporizadores.

Disciplina de medición: herramientas y cifras clave

Sin mediciones, cualquier optimización queda a ciegas. Yo registro los valores de base y los comparo después de cada cambio. Han demostrado su eficacia:

• encimera: Wakeups-from-idle/s, top originator, C-state residency
• turbostatFrecuencias, estados C del paquete y del núcleo, rendimiento de la RAPL
• estado perfectoConmutaciones de contexto, interrupciones de temporizador, ciclos, instrucciones
• /proc/interrupcionesDistribución de IRQ por CPU
• pidstat/iostatCaracterísticas de proceso y E/S

# Captura 10 minutos de línea base en modo inactivo
sudo turbostat --Summary --interval 5 --quiet --show PkgWatt,BUS,CPU,CPU,CPU,MHz
sudo powertop --time=600 --html=/tmp/powertop_baseline.html

Mapa de interrupciones #
watch -n2 'cat /proc/interrupts | sed -n "1,30p"'

# Conmutaciones de contexto y eventos de temporizador
perf stat -a --delay 5000 --timeout 60000 -e cs,task-clock,cpu-clock,irq_vectors:local_timer

En cada caso documento Consumo de energía en reposo (PkgWatt), cuotas de estado C, wakeups/s y métricas de latencia (p95/p99) de mi carga de trabajo relevante. Incluso las pequeñas diferencias se notan con el paso de las semanas.

Virtualización, contenedores y tickless en la pila

El hipervisor y los invitados juntos generan muchos Temporizador y wakeups, por ejemplo a través de cron, logging y agentes. Reduzco esta cadena activando Tickless en el hipervisor y en los sistemas invitados. Esto elimina los dobles wakeups y las CPU virtuales permanecen en silencio durante más tiempo. En entornos Kubernetes o de microservicios, el nivel de ruido de fondo desciende de forma apreciable. También sincronizo los tiempos de pods y lotes para que se creen ventanas de inactividad más largas y el Ahorro subir.

En entornos KVM, planifico la asignación de vCPUs y la afinidad de IRQs a la vez: asocio las IRQs de vNICs o vBlocks ruidosas a CPUs de mantenimiento, y las cargas de trabajo silenciosas a núcleos aislados. En cuanto a los huéspedes, desactivo las fuentes de temporizadores superfluas, reduzco las frecuencias de cron y utilizo temporizadores systemd con una precisión generosa (AccuracySec) para que los eventos se agrupen de forma más natural. Esto hace que las fases de inactividad sean más largas - el hipervisor se beneficia doblemente porque hay menos salidas y entradas de máquinas virtuales.

Configuración práctica: Perfiles de potencia, regulador, interrupciones

Suelo utilizar el regulador para reacciones rápidas schedutil porque intercepta dinámicamente los saltos de carga. Dejo activas las C-States, a menos que tengan prioridad latencias extremadamente cortas. Vinculo IRQs ruidosas a núcleos seleccionados y mantengo otros núcleos libres para que puedan dormir profundamente. Programo los trabajos por lotes, las copias de seguridad y las actualizaciones en bloques para agrupar las fases tranquilas. Si quieres saber más sobre esto, puedes encontrar información de fondo en Escalado de frecuencia de la CPU, que coordino estrechamente con Tickless para utilizar las propinas con moderación.

Además, ajusto el sesgo de preferencia energética (EPP/EPB) de las CPU modernas para que los boosts sólo se disparen cuando sea necesario y las residencias ociosas se mantengan altas. Los servicios con latencia tolerante reciben mayores valores de holgura del temporizador (systemd: TimerSlackNSec=), controlo los trabajos periódicos mediante temporizadores systemd con AccuracySec y RandomisedDelaySec. Esto reduce las cargas en los bordes y crea ventanas ociosas más largas y contiguas.

# Ejemplo: Asignar IRQ específicamente (Atención: compruebe el número de IRQ)
echo 0-1 | sudo tee /proc/irq/XX/smp_affinity_list # bind IRQ to housekeeping

# set systemd timer cooperatively (extracto de una unidad .timer)
AccuracySec=5min
RandomisedDelaySec=30min
Persistent=true

Utilice NUMA y la agrupación de cargas con sensatez

En hosts multinúcleo y NUMA, aumento el Eficacia, concentrando deliberadamente la carga en unos pocos núcleos. Como resultado, los núcleos libres caen más y durante más tiempo en estados C. Me aseguro de mantener los accesos a memoria NUMA-local para evitar aumentos innecesarios. El planificador de Linux ayuda, pero la fijación manual de los hilos calientes suele ser el toque final. Con Tickless, este pinning es más efectivo porque los núcleos aislados no se despiertan por periodicidades y, por lo tanto, los hilos reales no se activan. Descanso tener.

En la práctica, prefiero asignar los hilos de E/S intensivos al mismo nodo NUMA y aislar los servicios intensivos de CPU a unos pocos núcleos de este nodo. Los cgroups (cpuset, cpu) ayudan a trazar límites claros. Compruebo Transparent Huge Pages y AutoNUMA en función de la carga de trabajo: pueden ayudar, pero contrarrestan el jitter de latencia. Es importante que al menos un nodo conserve suficiente capacidad de housekeeping para que las tareas del sistema no irrumpan en los núcleos críticos.

Equilibrar y medir los requisitos de latencia

Algunas cargas de trabajo en tiempo real o de negociación requieren el menor tiempo posible. Tiempos de respuesta. Por ello, realizo pruebas con muestras cercanas a la producción y comparo los percentiles de latencia antes y después de los cambios sin cosquillas. NO_HZ_FULL puede reducir los cambios de contexto y el ruido del temporizador, pero los estados C profundos alargan ocasionalmente las rutas de activación. Con la telemetría de los estados C, la frecuencia, las latencias de los paquetes y el jitter, tomo decisiones informadas. Si también mantienes el kernel, te beneficias de varias maneras: el ajuste del rendimiento y las correcciones de seguridad van de la mano, como demuestra la práctica; mi referencia a Optimización del núcleo, que integro sistemáticamente en las ventanas de mantenimiento.

En concreto, pruebo escenarios de ráfagas (fases cortas e intensas) y correlaciono los picos de latencia con la frecuencia y las trazas de estados C. Para ello son útiles las mediciones con un EPP fijo, o bien una prueba breve con estados C limitados para visualizar la proporción de latencia de activación. Si se utilizan núcleos NO_HZ_FULL, me aseguro de que las CPU de mantenimiento no estén subalimentadas; de lo contrario, existe el riesgo de que se produzcan advertencias de RCU o fluctuaciones esporádicas.

Seguridad: Los núcleos actuales pagan dos veces

Tengo sistemas actual, porque los nuevos kernels no sólo perfeccionan las vías de ahorro de energía, sino que también cierran brechas. Los informes sobre vulnerabilidades del kernel muestran que los atacantes han sido capaces ocasionalmente de ampliar los derechos con poco esfuerzo. Con las actualizaciones, reduzco este riesgo y, al mismo tiempo, aseguro las ganancias de eficiencia de los mecanismos modernos [2]. En definitiva, la seguridad operativa aumenta y los tiempos de inactividad imprevistos no ponen a prueba los nervios ni el presupuesto. Es precisamente esta combinación de seguridad y Eficacia hace que las actualizaciones periódicas sean una decisión fácil.

Efecto centro de datos: PUE, ventiladores, fuentes de alimentación

Menos despertares reducen la Carga en la refrigeración y la distribución de la energía. Los picos de CPU son más suaves, los ventiladores funcionan con menos frecuencia al límite y las fuentes de alimentación trabajan de forma más eficiente. Este efecto dominó repercute directamente en el PUE de un sitio. Si quieres saber más, echa un vistazo al tema centro de datos ecológico y utiliza Tickless como componente básico de un sistema holístico de gestión energética. Siempre planifico las medidas conjuntamente, porque el hardware, el SO y la carga de trabajo contribuyen juntos a la Ahorro con.

Recorte práctico de WordPress, PHP y bases de datos

En pilas de CMS con muchos cortos Consultas Me benefician mucho las capas de caché y el ajuste limpio de PHP-FPM. Mantengo opcache caliente, sello los plugins Chatty y minimizo el ruido de cron apilando ventanas de tareas. A las bases de datos se les dan periodos de mantenimiento claros para que no empujen picos de E/S en la carga diaria. Junto con Tickless, el ruido de fondo disminuye y el servidor entra en reposo más rápidamente. De este modo, la plataforma combina el rendimiento por vatio sin que los usuarios experimenten un notable Pérdidas ver.

Específicamente, reduzco los disparadores cron de WordPress, muevo el trabajo recurrente a temporizadores systemd con coalescencia y mantengo los trabajadores PHP FPM dimensionados de tal manera que se atiendan olas de carga cortas sin mantener una alta base permanente de trabajadores abiertos. Las bases de datos se benefician de ventanas de autovacío claras (acelerar/mover cuando sea necesario) y "bloques de mantenimiento" consistentes. Prefiero agrupar cada tarea regular, pero no crítica en el tiempo, de una manera de grano grueso en lugar de dispararla en segundos.

BIOS/UEFI y rutas de hardware

Ya he sentado las bases en la BIOS/UEFI: activar los estados C profundos de los paquetes, usar sustratos ASPM/PCIe L1 y no desactivar las funciones de ahorro de energía en toda la placa. Solo limito la profundidad de los estados C a modo de prueba si lo requieren objetivos de latencia especiales. Las tarjetas de red y los controladores NVMe se benefician de los modos de ahorro de energía; no obstante, compruebo si la gestión agresiva de la energía genera picos de latencia. Merece la pena un equilibrio sensible: una marcha menos al máximo ahorro de energía puede tener un gran efecto en el rango de latencia de 99p.

Red y almacenamiento: sigue impulsando los despertares

La pila de red suele disparar muchas IRQ. Aumento cuidadosamente los parámetros de coalescencia para suavizar las tormentas de interrupciones sin empeorar innecesariamente la latencia:

# Ejemplo (¡ajuste los valores en función de la carga de trabajo!)
sudo ethtool -C eth0 rx-usecs 16 rx-frames 16 tx-usecs 16 tx-frames 16

Escalo GRO/LRO y RSS para que coincidan con la topología de la CPU, de modo que unos pocos núcleos soporten la mayor parte del ruido de las interrupciones. En cuanto al almacenamiento, compruebo si las propiedades del dispositivo (por ejemplo, NVMe-APST) ya están optimizadas y los picos de carga no se convierten en picos diarios debido a trabajos en segundo plano (depuraciones, reconstrucciones). El objetivo es empujar las ráfagas de E/S planificables hacia ventanas definidas.

Imágenes de errores y resolución de problemas

Las configuraciones sin cosquillas rara vez fallan debido a la mecánica básica, más a menudo debido a la puesta a punto:

• La UCR se estancaSi se produce NO_HZ_FULL, la causa suele ser que hay muy pocas CPUs de housekeeping o demasiada carga IRQ en los núcleos aislados. Prevea más capacidad de mantenimiento.
• Despertares inesperadosPowertop muestra los culpables. Las fuentes más frecuentes son los agentes de telemetría, los intervalos cortos de temporizador o los registros de chat.
• Distribución desigual de IRQComprobar /proc/interrupts y reajustar afinidades; configurar irqbalance correctamente.
• Fluctuación de latenciaLa profundidad del estado C, el EPP y la coalescencia varían gradualmente y observan el p99; a menudo basta con pequeños ajustes.

Para obtener resultados reproducibles, trabajo con ventanas de cambio, puntos de retroceso claros y parámetros documentados con precisión. Cada cambio se somete a una ronda de medición, y solo entonces se da el siguiente paso.

Pasos concretos para empezar

Empezaré con una corriente Núcleo y compruebo si NO_HZ_IDLE está activo. A continuación, mido las líneas de base: consumo de energía en reposo, temperatura, estados C, tasa de IRQ y latencia. Después activo las opciones tickless y repito las mediciones. Si encuentro ahorros, guardo la configuración en repos de código y documentación. Si es necesario, pruebo NO_HZ_FULL para los núcleos seleccionados y los aíslo con una cuidadosa asignación de IRQ para que el Efecto permanece visible.

Mi procedimiento pragmático:

1. Recopilar datos de referencia (10-15 minutos en reposo + breve prueba de carga, guardar métricas).
2. Compruebe NO_HZ_IDLE, valide el temporizador de alta resolución y el controlador de inactividad
3. Ajustar la afinidad IRQ e irqbalance, IRQs ruidosas en housekeeping
4. Aumentar la coalescencia del temporizador (temporizador systemd, TimerSlack, intervalos cron)
5. Opcional: NO_HZ_FULL en los núcleos seleccionados + rcu_nocbs, dejar libres al menos 1-2 CPUs de mantenimiento.
6. Ajuste de NUMA y CPU, límites de Cgroup y ventanas por lotes
7. Comparar antes y después, documentar las decisiones

Mi breve resumen

La ausencia de cosquillas aporta Energía- y térmicas, especialmente para cargas de trabajo flexibles con fases de inactividad más largas. Empiezo con NO_HZ_IDLE y lo combino con perfiles de potencia razonables. A continuación, trabajo en las afinidades IRQ, la agrupación de cargas y la disciplina de medición. Para escenarios especialmente críticos en cuanto a latencia, utilizo NO_HZ_FULL en dosis y evalúo la compensación con pruebas realistas [1]. Si combinas tecnología, diseño de cargas de trabajo y monitorización, puedes utilizar la Potenciales de esta función del núcleo de forma permanente.