Analizar y optimizar la carga de los SoftIRQ en Linux

Te voy a explicar paso a paso cómo SoftIRQ de Linux-Mido la carga de trabajo, identifico los cuellos de botella y recupero el control con unos pocos ajustes en el kernel. Para ello, doy prioridad a los efectos cuantificables: tiempos de respuesta más cortos Latencias, núcleos de CPU equilibrados y un procesamiento de paquetes estable bajo una elevada carga de red.

Puntos centrales

• Puntos de medición Comprender: /proc/softirqs, softnet_stat, interrupts
• Síntomas Detectar: carga de ksoftirqd, pérdida de paquetes, picos de latencia
• Sintonización controlar: netdev_budget y netdev_budget_usecs
• Distribución Guardar: afinidad de IRQ, RSS, asignación de colas
• Monitoreo Ejecutar: mpstat, perf, Tracing

Resumen de las SoftIRQ: cómo funciona el núcleo

Tras una interrupción de hardware, el núcleo traslada parte del trabajo a los denominados SoftIRQs, para que las rutas críticas se desocupan rápidamente y el procesamiento siga siendo previsible. Especialmente en la ruta de red, los controladores NAPI recogen los paquetes de los anillos de las tarjetas de red, inician el procesamiento del protocolo y transfieren los datos al Pila de red. Si aumenta el volumen de eventos, intervienen los subprocesos por CPU, como ksoftirqd/cpuN, y se encargan del sondeo y del procesamiento posterior. Esta desacoplamiento mejora el rendimiento global, pero en caso de sobrecarga puede provocar tiempos de ejecución prolongados de las SoftIRQ en algunos Núcleos provocar. Por eso, compruebo desde el principio si predominan las rutas NET_RX y NET_TX y si ksoftirqd consume de forma evidente tiempo de CPU. Así detecto cuándo las SoftIRQ se convierten en un cuello de botella y otras Optimizaciones son necesarios.

Detectar los síntomas típicos de una elevada carga de SoftIRQ

Lo primero que me indica una carga elevada de SoftIRQ es un nivel constantemente alto de CPU del núcleo y los procesos ksoftirqd, que se mantienen en picos durante muchos segundos. Paralelamente, aumentan las latencias en las E/S de red y de bloque, lo que se traduce en lentos procesos de establecimiento de conexión TLS o en un funcionamiento lento APIs se manifiesta. A menudo se acumulan las pérdidas de paquetes, mientras que los anillos de la tarjeta de red se saturan y aumentan los atascos. Cuando las interrupciones están mal distribuidas, la CPU 0 suele verse muy afectada, ya que muchas líneas de IRQ, junto con el trabajo derivado, se concentran en una Núcleo aterrizar. Esta limitación a un solo núcleo aumenta los tiempos de espera de los servicios y reduce el rendimiento efectivo. Por eso estoy comprobando si se trata de un patrón sistemático o si solo se debe a Picos conduce a.

Puntos clave de medición: cómo interpretar correctamente /proc y las herramientas

Empezaré por /proc/softirqs, ya que allí puedo ver, por cada CPU y tipo, en qué medida, más o menos, NET_RX, NET_TX, TIMER o BLOCK. En /proc/net/softnet_stat reviso las líneas prestando especial atención a los campos que indican presupuestos no alcanzados o paquetes descartados, lo que, ante un aumento constante, indica claramente que Ciclos de sondeo indica. /proc/interrupts revela si las interrupciones de hardware se distribuyen de forma desigual entre las CPU y cuáles son las IRQ más activas. Herramientas como mpstat, top o htop me ayudan a identificar ksoftirqd/cpuN y a determinar la distribución de las Tiempos de Softirq evaluar por núcleo. Si es necesario, perf proporciona puntos críticos en la pila para que pueda identificar los manejadores y las rutas de los controladores que consumen más tiempo. La siguiente tabla resume los puntos de medición más importantes, los indicadores y los típicos Acciones juntos.

Punto de medición	Ámbitos e indicadores más importantes	interpretación	Acción
/proc/softirqs	NET_RX, NET_TX, BLOCK por CPU	Se aprecia una distribución desigual de la carga	Ajustar la afinidad de IRQ, activar RSS
/proc/net/softnet_stat	Contador de presupuesto/caídas, tercero Columna	Los presupuestos son demasiado reducidos y los paquetes se quedan sin recoger	Aumentar netdev_budget/usecs, comprobar RPS
/proc/interrupciones	Líneas IRQ por CPU, asignación de colas	Demasiadas IRQ en pocos núcleos	Comprobar irqbalance, configurar smp_affinity
mpstat / perf	%soft, puntos de acceso, Pilas	Se ven los nudos y las fibras dominantes	Dar prioridad al ajuste de los controladores y la pila

Causas y patrones de carga elevada

Los picos suelen deberse a un nivel muy alto de Rendimiento, muchas conexiones paralelas o ráfagas UDP que dominan NET_RX. A veces, los valores predeterminados de los controladores prevén lotes pequeños, lo que genera demasiadas interrupciones y sobrecarga a ksoftirqd, mientras que GRO/LRO quedan sin utilizar sigue siendo. Las afinidades desfavorables concentran la carga de trabajo en la CPU 0, aunque habría varias colas disponibles y el RSS podría facilitar la distribución. En las máquinas virtuales, las vNIC sobrecargan el núcleo del host, lo que aumenta los tiempos de SoftIRQ en el host a expensas de los invitados aumenta. Las superposiciones de contenedores añaden paquetes adicionales a la pila, lo que hace que los flujos sencillos se conviertan de repente en rutas más complejas. Solo la combinación de distribución, presupuesto y Dosificación Da como resultado una imagen completa.

Supervisión específica: hacer visibles las SoftIRQ

Para llevar a cabo un seguimiento eficaz, leo con regularidad /proc-Selecciono las interfaces y las relaciono con métricas del host, como la carga y las latencias de programación. Correlaciono los aumentos de NET_RX con los contadores de paquetes perdidos para determinar si solo aumenta el rendimiento o si se pierden paquetes en el trayecto. permanezca en. mpstat me proporciona, por cada CPU, los porcentajes de tiempo dedicados a las SoftIRQ, mientras que top/htop muestran los hilos ksoftirqd/cpuN que llaman la atención. Con perf record/perf top aíslo las rutas costosas, por ejemplo, las descargas de sumas de comprobación, la fusión de GRO o qdisc-Trabajo. Los rastros basados en eBPF o ftrace muestran el inicio y el final de los controladores, lo que me permite evaluar los tiempos de ejecución de los controladores y los efectos de la programación. De este modo, se obtiene una visión clara de la situación a partir de métricas, cronologías y Puntos de acceso.

Ajuste con netdev_budget y netdev_budget_usecs

Si la ruta NAPI es demasiado corta, la aumento poco a poco net.core.netdev_budget y net.core.netdev_budget_usecs, para procesar más paquetes por ciclo de sondeo. Para ello, observo la tercera columna de /proc/net/softnet_stat; si el aumento disminuye, los cambios dan en el blanco y las latencias se más corto. Aumento los valores de forma moderada, por ejemplo, de 300 a 600 paquetes y de 2000 a 4000 microsegundos, y compruebo si las demás tareas conservan suficiente tiempo de CPU. Un exceso bloquea el programador, por lo que controlo de cerca los picos de carga, los cambios de contexto y la longitud de la cola de ejecución acompaña. Además, conviene comprobar los valores de RPS/RFS, GRO/LRO y la MTU para aprovechar adecuadamente el agrupamiento de paquetes y el tamaño de los mismos. Para reducir las avalanchas de interrupciones, tengo en cuenta Coalescencia de interrupciones y ajusta los mismos detalles con los controladores NIC, si esta opción está disponible es.

Optimizar la distribución de interrupciones y la afinidad de IRQ

Para evitar cuellos de botella en un solo núcleo, distribuyo las IRQ entre varios CPUs, ya sea mediante irqbalance o con máscaras manuales de smp_affinity. Para ello, me baso en las colas de las tarjetas de red existentes y activo RSS, de modo que el hardware distribuya los flujos entrantes de manera uniforme y cada núcleo pueda trabajar con mayor facilidad lotes . Me aseguro de no mezclar las IRQ de control con las rutas de datos críticas para preservar la localidad de la caché y la previsibilidad. Unas afinidades correctamente configuradas reducen las latencias y minimizan las pérdidas, ya que el procesamiento posterior de las SoftIRQ ya no se queda atascado en un núcleo sigue siendo. Los controladores suelen mostrar las asignaciones de colas a la CPU en sysfs; allí compruebo si cada cola tiene un núcleo adecuado y si no se producen asimetrías. Para profundizar más, me guío por guías como Afinidad IRQ, para tener en cuenta también los aspectos relacionados con NUMA y el efecto de la caché tener en cuenta.

Guía práctica: De los síntomas a la solución

Para empezar, compruebo los síntomas: ksoftirqd/cpuN en «top», porcentajes de SoftIRQ por núcleo en mpstat y picos llamativos de NET_RX. A continuación, recopilo datos concretos de /proc/softirqs, /proc/net/softnet_stat y /proc/interrupts para identificar las rutas dominantes y las distribuciones desequilibradas. A continuación, realizo pequeños ajustes, primero en los presupuestos de netdev, seguidos de la afinidad de IRQ y el RSS, en cada caso con un minucioso Controlar. Si siguen apareciendo pérdidas de paquetes, compruebo la configuración de los controladores, las opciones de coalescencia, las descargas y el comportamiento de GRO/LRO. En hosts de máquinas virtuales o contenedores, evalúo además cómo interactúan las vNIC con la pila del host físico y dónde se producen las Puntos de acceso realmente sea así. Evalúo cada cambio a través de series temporales, hasta que las métricas y las latencias se estabilicen en un buen nivel terreno.

Buenas prácticas para un rendimiento sostenible

Voy a implementar un seguimiento periódico de los contadores SoftIRQ, ya que solo unos valores constantes Transparencia evita que se vuelvan a producir cuellos de botella. Las versiones actuales del núcleo resultan muy útiles, ya que NAPI y Stack se siguen mejorando internamente, lo que proporciona reservas para situaciones difíciles Cargas crear. Es imprescindible mantener una distribución equilibrada entre varios núcleos, así como contar con presupuestos razonables que recojan suficientes paquetes sin saturar el programador. Para perfiles de alojamiento con mucho tráfico HTTPS y de API, merece la pena echar un vistazo a SoftIRQ en el alojamiento web, ya que ahí se pone de manifiesto hasta qué punto la elección de las NIC, las colas y el ajuste mejoran la calidad del servicio. En la planificación de la capacidad, tengo en cuenta los núcleos de CPU, las características de las NIC, la memoria y las zonas NUMA, para que haya reservas disponibles antes de Consejos llegar. De este modo, la plataforma sigue siendo resistente y responde correctamente a los picos estacionales o a los provocados por las campañas Horas punta.

softnet_stat en detalle: qué significan realmente las cifras

Para repasar de forma específica, leo /proc/net/softnet_stat a lo largo del proceso e interpreta, en particular, las primeras columnas. Las casillas iniciales recogen los paquetes procesados y descartados por cada CPU, los tercera columna indica que hay presión de tiempo (en resumen: presupuesto o margen de tiempo insuficientes, NAPI debe interrumpirse). Si los «drops» o la presión de tiempo crecen de forma lineal con la carga, los presupuestos o la coalescencia son las primeras medidas a tomar. Por el contrario, si observo picos sin un aumento sostenido, las ráfagas solo aglomeran el trabajo a corto plazo; en ese caso, el procesamiento por lotes (GRO) suele ser más útil que los grandes presupuestos. Los kernels más recientes amplían las estadísticas con campos para RPS/RFS y límites de flujo; si estos aumentan, distribuyo de forma más consciente a través de RPS o reduzco RFS cuando sus consultas resultan más costosas que su beneficio. Siempre correlaciono los contadores con /proc/softirqs: Si NET_RX aumenta en núcleos individuales junto con la presión de tiempo en softnet_stat, me centro primero en la distribución (IRQ/RSS) y, solo en un segundo momento, en presupuestos más amplios.

RPS/RFS y XPS: control total de la gestión del software y el ajuste de colas

Si no hay RSS por hardware o este no es suficiente, configuro RPS (Receive Packet Steering), para distribuir la carga de recepción entre varios núcleos. A través de rps_cpus, asigno a las colas de recepción aquellos núcleos que se ajustan a los trabajadores activos y, en la medida de lo posible, Cerca de NUMA están. En muchos flujos, añado RFS (Receive Flow Steering), para que los paquetes entrantes lleguen al lugar donde se procesan los sockets correspondientes; esto es bueno para la localidad de la caché, siempre y cuando las tablas de flujos no se conviertan en un cuello de botella. Por el lado del emisor, ayuda XPS (Transmit Packet Steering), la elección de la cola de transmisión (TX) para adaptarla a la vinculación de la aplicación con la CPU. El objetivo es que un flujo se procese de forma coherente a través de la misma cola de recepción/transmisión (RX/TX) y del mismo núcleo, lo que reduce las latencias y GRO-Los lotes se hacen más grandes. Siempre pruebo las distribuciones por etapas: primero activo el RPS en unas pocas colas, mido el efecto (caídas, %soft, latencias) y, a continuación, añado el RFS/XPS. Si los núcleos se saturan debido al RPS o si empeora la tasa de aciertos de L3, vuelvo a reducir las máscaras de CPU o vinculo las colas más estrechamente a los núcleos de los servicios en cuestión.

NUMA, aislamiento de CPU e interacciones entre programadores

Por muy buenos que sean los presupuestos y las distribuciones, de poco sirven si los accesos a la memoria recorren largas rutas NUMA. Me aseguro de que las interrupciones de la tarjeta de red, el procesamiento posterior de NAPI y los procesos solicitantes se encuentren, en la medida de lo posible, dentro de la misma Dominio NUMA permanecen. En configuraciones con núcleos dedicados en tiempo real o de baja latencia, los aíslo mediante políticas de CPU y Cgroup, y evito deliberadamente que las interrupciones SoftIRQ se ejecuten en ellos. ksoftirqd No debería acabar en núcleos aislados, ya que, de lo contrario, los paquetes se acumularían sin que nadie se diera cuenta. Por el contrario, los núcleos aislados no deben quedarse totalmente sin atención de IRQ cuando terminan rutas de datos: una clara afinidad y Servicio de limpieza- La estrategia es imprescindible. Para cargas de trabajo con SLO estrictos, evito prioridades SCHED_FIFO/RR demasiado agresivas que podrían desplazar la ejecución de NAPI. Superviso las longitudes de las colas de ejecución, los despertares y las tasas de preeminencia: si los tiempos de SoftIRQ aumentan a medida que crece la interactividad de la aplicación, ajusto la granularidad y las afinidades, en lugar de aumentar los presupuestos de forma generalizada.

qdisc, descargas y Busy-Poll: equilibrar la latencia y el rendimiento

En la ruta de salida, cada uno cuesta qdisc-Tiempo de CPU de la operación. Elijo la disciplina que mejor se adapta al perfil: fq_codel ayuda a evitar el «puffer bloat» y suaviza los picos de tráfico, mientras que mq-Variantes de tarjetas de red con colas múltiples. En el caso de un rendimiento de datos puro en enlaces estables, un qdisc más ligero puede minimizar los picos de latencia. En la entrada, merece la pena ajustar con precisión GRO/TSO/GSO: Los lotes más grandes reducen la frecuencia de las interrupciones SoftIRQ, pero, en casos extremos, aumentan el tiempo de permanencia de los paquetes en la pila. Compruebo si los intervalos de vaciado de GRO o las descargas de hardware dan lugar a agregados demasiado grandes que puedan perjudicar a la aplicación. Para rutas en las que la latencia es muy crítica, configuro busy_poll y utilizo «busy_read» de forma moderada para extraer paquetes activamente del controlador, aunque solo bajo estrecha supervisión, para que otras tareas no se queden sin recursos. Del mismo modo, configuro Coalescencia de interrupciones En cuanto a los picos de tráfico: aumentar el tiempo de espera unos pocos microsegundos mejora el rendimiento, pero un aumento excesivo retrasa los ACK y alarga los procesos de establecimiento de conexión. Es importante evaluar cada cambio por separado: los picos simulados, los picos reales de producción y los periodos de inactividad suelen presentar perfiles de latencia diferentes.

Lista de comprobación para el diagnóstico y reversión segura

Sigo sistemáticamente una breve lista de comprobación para abordar los cambios: 1) Comprobar los síntomas (ksoftirqd, %soft, caídas). 2) Comprobar la distribución (/proc/interrupts, Queue->CPU, estado RSS/RPS). 3) Ajustar los presupuestos, comprobar el efecto en softnet_stat Observar (la presión de tiempo disminuye, los «drops» se estancan). 4) Ajustar con precisión las descargas y la fusión, revisar el qdisc. 5) Verificar las asignaciones NUMA/CPU y los cgroups. Cada paso termina con una mejora clara de las métricas o con el Rollback hasta el último estado óptimo. Documento los valores objetivo y reales (latencia P95/P99, %soft por núcleo, tasas de caída, cambios de contexto) para que las iteraciones posteriores no se realicen a ciegas. Si varias pequeñas mejoras no suponen un alivio, interrumpo el proceso y busco causas estructurales (cuellos de botella en las colas, bloqueos de aplicaciones, influencias del almacenamiento). Esta disciplina evita las correlaciones erróneas y protege contra las espirales de optimización que, aunque aumentan las cifras de rendimiento, empeoran la interactividad y la estabilidad.

Separar claramente los casos límite y los perfiles de carga de trabajo

Distingo deliberadamente entre transferencias masivas, API con latencia crítica y tráfico intermitente UDP-Tráfico. Para datos masivos, recurro antes al procesamiento por lotes y a la fusión, siempre que no se produzcan pérdidas de paquetes. En el tráfico de API, doy prioridad a una distribución uniforme, a lotes limitados y a latencias E2E estables, incluso si el rendimiento máximo nominal desciende ligeramente. Para combatir las ráfagas de UDP, prefiero recurrir a la ampliación de colas y a las afinidades; de lo contrario, unos presupuestos demasiado grandes solo aumentan el bloqueo de cabeza de cola. Si un entorno utiliza muchos saltos de contenedores o de superposición, preveo una carga adicional en la pila y distribuyo más ampliamente la carga de SoftIRQ. Además, evalúo por separado las sobrecargas del cortafuegos y de Conntrack: cuando las tablas alcanzan sus límites, la carga de SoftIRQ aumenta inevitablemente, por muy buena que sea la distribución de IRQ. Solo cuando las rutas por perfil son consistentemente ligeras, merece la pena ajustar con precisión los últimos porcentajes.

SoftIRQ en entornos de nube y contenedores

En entornos virtualizados, la carga se desplaza a través de vSwitches, redes superpuestas y pilas de host, por lo que tengo que tener en cuenta tanto el entorno invitado como el host-Métricas Analízalo. Los tiempos elevados de SoftIRQ en el host ralentizan inmediatamente los contenedores y las máquinas virtuales, incluso aunque los sistemas invitados parezcan funcionar sin problemas. trabajo. Por eso compruebo las descargas y la fusión en la tarjeta de red física, mientras que RPS/RFS en el host distribuye mejor la ruta de software. Para las cargas de trabajo en contenedores, compruebo si los límites de Cgroup para la CPU y el procesamiento de IRQ están configurados de forma adecuada, para que los servicios importantes no se vean afectados por Colas morir de hambre. Las vNIC compatibles con colas múltiples y con RSS mejoran el paralelismo, siempre que las afinidades y las asignaciones de colas sean las adecuadas. Con este enfoque, mantengo las rutas de datos cortas y estabilizo Latencias y un rendimiento seguro y reproducible.

Resumen: Dominar con soltura el análisis de SoftIRQ

Quien analiza correctamente la carga de SoftIRQ, utiliza puntos de medición claros, examina las distribuciones y establece Pasos. Empiezo por /proc/softirqs y softnet_stat, establezco una correlación con ksoftirqd y mpstat y, a partir de ahí, deduzco el orden de mis Medidas. Primero ajusto netdev_budget y netdev_budget_usecs; después optimizo la afinidad de IRQ, el RSS y las opciones de procesamiento por lotes, como GRO y las descargas. Cada ajuste es mínimo, se mide y solo se mantiene si tiene un efecto positivo, hasta que desaparezcan las pérdidas y Latencias disminuir. Esta disciplina evita los efectos secundarios, mantiene la interactividad en la CPU y garantiza el funcionamiento de los servicios incluso en momentos de picos de tráfico receptivo. De este modo, el rendimiento de Linux sigue siendo transparente, robusto y adaptable, sin que haya puntos críticos ocultos que Estabilidad poner en peligro.