Gestión de interrupciones en servidores: cómo afectan las interrupciones de la CPU al rendimiento

Las interrupciones de la CPU controlan la rapidez con que mi servidor responde a los paquetes de red, los eventos de almacenamiento y los temporizadores: las interrupciones mal distribuidas o demasiado frecuentes ralentizan las aplicaciones de forma apreciable. Un servidor con una gestión limpia de las interrupciones reduce los cambios de contexto, disminuye las latencias y estabiliza los tiempos de respuesta durante los picos de carga.

Puntos centrales

Resumiré los siguientes aspectos clave antes de entrar en detalles:

• Carga de interrupción comprender: Cuándo los valores porcentuales se vuelven críticos
• Paralelismo gestionar: interrupciones simultáneas y latencias en el peor de los casos
• MSI-X utilizar: Más noticias, mejor distribución
• RSS & Affinity: Colocar las interrupciones NIC en los núcleos
• Monitoreo establecer: Leer los números, actuar con determinación

Qué provoca las interrupciones de la CPU en los servidores

Una interrupción es un Señal, que saca inmediatamente a la CPU de su tarea actual e inicia un gestor. Las tarjetas de red informan de nuevos paquetes, los controladores de almacenamiento señalan E/S completadas, los temporizadores activan relojes... cada una de estas interrupciones cuesta dinero. tiempo de CPU. Con una alta actividad, estos eventos se suman a muchos cambios de contexto y pérdidas de caché. Por lo tanto, monitorizo con qué frecuencia y cuánto tiempo pasa la CPU en el kernel en ISRs y DPCs. Si entiendes estas dinámicas, podrás controlar los tiempos de respuesta de forma fiable y mantener las aplicaciones funcionando de forma notablemente más fluida.

Por qué los tiempos de interrupción elevados cuestan rendimiento

En entornos sanos, las interrupciones del sistema suelen ser entre 0,1-2% CPU, 3-7% son posibles a corto plazo. Si el tiempo de interrupción se mantiene regularmente por encima de 5-10%, suele haber detrás un problema de drivers, hardware defectuoso o un ajuste incorrecto. A partir de 30% la cosa se pone seria, más allá de 50% existe la amenaza de Cuellos de botella y tiempos de respuesta lentos. Las aplicaciones pierden rendimiento, las latencias saltan y la previsibilidad se resiente. Entonces compruebo primero las versiones de los controladores, el firmware, las afinidades y la moderación de las interrupciones en las NIC.

Interrupciones simultáneas: comprender las latencias

Una sola interrupción rara vez sigue siendo una Problema; Se complica cuando varios eventos colisionan. Si una interrupción de alta prioridad se produce durante una interrupción de baja prioridad, su procesamiento se prolonga con más interrupciones. Un ejemplo: si la ruta de alta prioridad requiere 75 ciclos y la de baja prioridad 50, la latencia de la ruta de baja prioridad aumenta fácilmente a 125 ciclos - más solapamientos aumentan la latencia. En el peor de los casos-la latencia aumenta rápidamente. Este comportamiento hace que los sistemas sean impredecibles. Por ello, planifico las afinidades y prioridades del núcleo de forma que los hotpaths no se bloqueen entre sí.

MSI y MSI-X en la vida cotidiana

Los hosts modernos utilizan MSI o MSI-X, en lugar de enviar las clásicas señales de línea (líneas IRQ). MSI transmite el mensaje como una escritura en memoria, reduciendo así la latencia y la susceptibilidad a las interferencias. MSI-X amplía el concepto: más mensajes, colas separadas, distribución más precisa a los núcleos. Esto reduce las colisiones de interrupciones y mejora la Escala con alto rendimiento. Activo MSI-X para NIC y controladores NVMe, siempre que los controladores y el firmware lo admitan de forma estable.

mecanismo	Max. Mensajes	Dirección	Distribución a núcleos	Efecto típico
IRQ heredada	1 por aparato/línea	Señal de línea	Restringido	Más alto Latencia, más colisiones
MSI	Hasta ~32	Escritura en memoria (16 bits)	Bien	Menos gastos generales, trayectorias más estables
MSI-X	Hasta 2048	Escritura en memoria (32 bits)	Muy buena	Más fino Distribución, mayor paralelismo

DMA, DPC y la ruta de datos correcta

Con DMA, los dispositivos pueden almacenar datos directamente en el Memoria La CPU sólo activa las rutinas de procesamiento. Esto ahorra interrupciones porque hay que señalar menos estados intermedios. Me aseguro de que los CPDs agrupen el trabajo real en lugar de hacer demasiado en el ISR. Esto mantiene el tiempo en la sección crítica corto y el Latencia más predecible. En general, la CPU gana más tiempo para la lógica de la aplicación.

Configurar específicamente el RSS y la afinidad de la CPU

El escalado del lado de recepción distribuye las colas de red y sus interrupciones entre varias núcleos. Vinculo todas las colas, incluidas las de interrupción, DPC e hilo de usuario, al mismo núcleo o grupo de núcleos para evitar que se activen varios núcleos. Si en un flujo participan distintos núcleos, aumentan las pérdidas de caché y los cambios de contexto. Un plan de afinidad estructurado evita notablemente estas pérdidas por fricción. Si quieres profundizar más, puedes encontrar una compacta Afinidad CPU-Vista general de las configuraciones de alojamiento.

Desactive las interrupciones de almacenamiento y las rutas de E/S

El almacenamiento también genera muchos Interrupciones, especialmente con muchas IOPS pequeñas. Utilizo MSI-X en controladores NVMe y asigno colas a núcleos fijos para que la entrada y la salida sigan siendo locales. Además, un Programador de E/S, para suavizar la carga por cola. Las variantes Deadline, BFQ o MQ reaccionan de forma muy diferente en función de la carga de trabajo. Si realiza las pruebas correctamente aquí, reducirá el jitter y aumentará el Rendimiento.

Tormentas de red, inundaciones SYN y moderación de interrupciones

Las repentinas avalanchas de paquetes ISR-tasa y dejan sin aliento a la CPU. Activo la moderación de interrupciones en la NIC para que los paquetes lleguen en ráfagas razonables sin generar picos de latencia. Para escenarios de DoS, un SYN defensa contra inundaciones la tabla de conexiones en una fase temprana. Al mismo tiempo, mido si la propia moderación reacciona con demasiada lentitud - entonces ajusto los valores. El objetivo es conseguir un flujo de paquetes fluido que distribuya uniformemente los CPD. alimenta.

Seguimiento: leer las cifras y actuar en consecuencia

Empiezo con unas pocas, claras MétricasUtilización total de la CPU, tiempo de interrupción, tiempo de CPD, cambio de contexto y cola del procesador. Si la CPU se mantiene normalmente por debajo de 50%, reacciono con calma; a 50-80% observo picos y puntos calientes; por encima de 80% planifico el escalado o el ajuste. Si el tiempo de interrupción sube por encima de 30%, compruebo el controlador, el firmware y las afinidades. Una comprobación de la latencia de audio/vídeo muestra indirectamente la determinación con la que reacciona el kernel. Importante: Sólo cambio una Variable por prueba y, a continuación, medir de nuevo.

Topología NUMA y localidad PCIe

En hosts multi-socket, siempre decido las afinidades de interrupción en el contexto del NUMA-topología. Una NIC o un controlador NVMe está conectado físicamente a un complejo raíz PCIe y, por tanto, a un nodo NUMA. Si configuro las colas y sus interrupciones a distante núcleos, los datos viajan a través de enlaces UPI/QPI - las latencias aumentan, el ancho de banda disminuye. Por lo tanto, compruebo a qué nodo NUMA está asignado un dispositivo, vinculo sus colas a los núcleos locales y me aseguro de que los hilos de usuario asociados utilicen el mismo nodo. En Windows, presto atención a los grupos de procesadores y a la configuración del dispositivo para el nodo NUMA preferido; en Linux, vinculo sistemáticamente las IRQ, las softirq y los hilos de aplicación al nodo local. El resultado: menos tráfico entre nodos, más estabilidad... Jitter-y latencias calculables en el peor de los casos.

Uso correcto de offloads, NAPI y coalescing

Las descargas son poderosas palancas contra las inundaciones de interrupciones, pero deben utilizarse para Carga de trabajo en forma. En resumen: TSO/GSO trasladan la segmentación a la NIC, LRO/GRO resumen los segmentos entrantes, RSC en el host tiene un efecto similar a LRO. Para transferencias masivas (copia de seguridad, replicación), estas características aumentan el rendimiento y reducen significativamente la tasa de ISR. Sin embargo, para los flujos de latencia crítica (RPC, comercio, VoIP), las grandes agregaciones pueden tener un impacto negativo en la tasa de ISR. Tiempos de respuesta extender. Por lo tanto, elijo una configuración moderada: GRO sí, pero no te pases; LRO sólo si no hay dispositivos de camino medio o cortafuegos que causen problemas; deja TSO/GSO activos como norma.

NAPI en Linux cambia del modo de interrupción pura al modo de sondeo a partir de la carga. Esto suaviza los picos y mantiene la CPU ocupada en la ruta del CPD en lugar de disparar miles de ISRs cortas. Junto con Interrumpir la moderación (coalescencia), se crea un plan: temporizadores cortos para los perfiles interactivos, temporizadores más largos para los masivos. Pruebo intervalos en incrementos de microsegundos, observo caídas, niveles de llenado de anillos y latencias para encontrar el punto óptimo. En la pila de almacenamiento, los tornillos de ajuste analógicos (profundidad de la cola, NCQ, optimizaciones blk-mq) producen el mismo efecto: menos staccato, más Eficacia.

Equilibrio de IRQ frente a fijación estática

El equilibrado automático de IRQ distribuye la carga de forma aceptable, pero no perfecta. En entornos web homogéneos, suelo dejarlo funcionando y sólo controlo los hotspots. En configuraciones de latencia crítica o asimétricas Fijación estática superior: Defino conjuntos de CPU fijos para cada cola y dispositivo, los mantengo consistentes mediante reinicios y minimizo la migración de softirqs. Además, reservo núcleos „domésticos“ para el trabajo en segundo plano (temporizadores, Kthreads), de modo que los núcleos de rendimiento permanezcan libres. En Windows, utilizo específicamente la dirección de interrupciones y máscaras de afinidad para cada cola; en Linux, trabajo con afinidad por IRQ y control Softirq. El lema: tanta automatización como sea necesaria, tanta Determinismo como sea posible.

Virtualización y SR-IOV/virtio

En las máquinas virtuales surgen costes adicionales: las interrupciones virtuales implican Salidas VM, retrasos en la programación y colas compartidas. Conecto las vCPU de E/S intensivas a las pCPU adecuadas, evito el exceso de compromisos en los hosts de E/S y separo los subprocesos del plano de datos de la carga de gestión. En la medida de lo posible, utilizo SR-IOVLas funciones virtuales llevan MSI-X a la máquina virtual invitada y reducen la carga en la ruta del hipervisor. Para cargas de trabajo genéricas, virtio con aceleración vhost ofrece resultados sólidos; en escenarios de alto rendimiento, asigno colas 1:1 a vCPUs y mantengo afinidades consistentes de huésped a host. Importante: Las mismas reglas para RSS, coalescing y NUMA también se aplican en las máquinas virtuales: sólo la Transparencia es menor, así que mido más de cerca.

Gestión de la energía y latencias deterministas

Las funciones de ahorro de energía son buenas para el balance, pero malas para el duro Presupuestos de latencia. Los estados C profundos prolongan el tiempo de activación y los cambios de frecuencia agresivos provocan fluctuaciones. En hosts con SLO estrictos, establezco perfiles de rendimiento, limito los estados C profundos del paquete y sólo permito el turbo cuando la reserva térmica es suficientemente grande. Las decisiones sobre los temporizadores (temporizadores de alta resolución frente a una frecuencia de interrupción más baja) también influyen en la cantidad y el ritmo de trabajo del núcleo. En configuraciones cercanas al tiempo real, los modos sin tictac y los núcleos aislados ayudan: los hilos de aplicación en núcleos aislados, el trabajo del sistema en núcleos dedicados al „mantenimiento“. Camino caliente libre de fuegos que interfieran.

Herramientas y metodología de medición por sistema operativo

Mantengo mi Cadena de diagnóstico y reproducible. En Linux empiezo con /proc/interrupts y /proc/softirqs, compruebo los contadores por cola mediante ethtool e investigo los ajustes de coalescencia y descarga. mpstat, vmstat y sar muestran macrotendencias; perf descubre puntos calientes en ISRs/DPCs. Correlaciono los contadores de paquetes y caídas con los tiempos del kernel y las métricas de flujo. En Windows, los indicadores de rendimiento de tiempo de interrupción/DPC, interrupciones/segundo y DPC/segundo proporcionan una imagen clara; las trazas muestran qué controladores están marcando el reloj. Importante es la Escala de tiempoRegistro todo sincronizado para que coincidan los picos, las caídas y los saltos de latencia.

Manual de solución de problemas y antipatrones

Mi procedimiento es coherente: primero Observe, luego hipótesis, luego un cambio. Causas típicas: una cola o un dispositivo con una tasa de ISR en aumento, firmware defectuoso, valores de coalescencia demasiado altos (sistema duro) o demasiado bajos (tormenta de ISR), descargas que se agrupan demasiado grandes o hilos que tiran de las colas a través de nodos NUMA. Aíslo el dispositivo afectado, pruebo los valores predeterminados conservadores, ajusto los controladores/BIOS y distribuyo la carga limpiamente. Anti-patrón: mover todo al mismo tiempo, rollbacks desordenados, sin línea de base o lecturas sin contexto. Si usas persistentemente un Variable uno tras otro, acabará rápidamente con una configuración estable.

Blueprints para hosts 10/25/100G y NVMe

Para NICs 10G, calculo 4-8 colas RSS, dependiendo de la generación de CPU y el perfil de paquetes. Empiezo coalesciendo moderadamente (por ejemplo, microsegundos de dos dígitos bajos), GRO activado, LRO con cuidado. A los 25G escalo a 8-16 colas y mantengo la afinidad estrictamente NUMA-local. A partir de 40/100G, la arquitectura de colas se convierte en la Tarea principalMuchas colas, asignación limpia por núcleo, descargas activas, NAPI surte efecto bajo carga. Para el almacenamiento NVMe, asigno al menos una cola por núcleo y mantengo la profundidad de la cola adecuada para la carga de trabajo: las E/S pequeñas se benefician de un mayor paralelismo, las transferencias secuenciales grandes de una política de coalescencia estable y un programador que suaviza las ráfagas. El objetivo sigue siendo el mismo: latencias constantes, sin núcleos calientes, sin anillos desbordados.

Lista de control práctica para un éxito rápido

Actualizo primero Conductores y la BIOS/firmware, porque los estados defectuosos suelen aumentar la carga de interrupciones. Luego, si es posible, cambio a MSI-X y distribuyo las colas limpiamente entre los núcleos. Configuro el RSS para que las afinidades de flujo sean correctas y los hotpaths se mantengan coherentes. En la NIC, adapto la moderación al perfil de tráfico y observo el efecto en las latencias. Si sigo encontrando valores atípicos, busco hardware defectuoso, opciones incorrectas o dispositivos problemáticos utilizando el procedimiento de exclusión y un Perfil.

Evaluar de forma realista los costes y beneficios

No todos los sistemas necesitan el máximo Ajuste fino. Doy prioridad a los hosts con una gran carga de paquetes, muchas IOPS pequeñas o especificaciones de latencia ajustadas. Unas pocas horas de ajuste compensan enormemente, ya que una menor sobrecarga de interrupciones libera inmediatamente CPU para la aplicación. En servidores no críticos, basta con una configuración básica sólida con los últimos controladores y MSI-X. Me guío por los valores medidos, no por corazonadas o Supuestos.

Resumen: Lo que meto en el mantenimiento diario

Observo sistemáticamente Interrumpir- y DPC, mantengo los controladores y el firmware actualizados y utilizo MSI-X siempre que es posible. Planifico RSS y afinidades por carga de trabajo para que los flujos, los DPC y los hilos permanezcan locales. Adapto la moderación de las NIC a los patrones del tráfico, distribuyo limpiamente las colas de almacenamiento y utilizo rutas de E/S adecuadas. Si la supervisión muestra valores atípicos, me abro camino directamente a través de los controladores, el hardware y la configuración. De este modo, el servidor de gestión de interrupciones sigue siendo predecible y mis cargas de trabajo se ejecutan con estabilidad. Actuación.