{"id":21347,"date":"2026-09-13T08:35:03","date_gmt":"2026-09-13T06:35:03","guid":{"rendered":"https:\/\/webhosting.de\/linux-softirq-auslastung-analysieren-performance-tuning-datacenter\/"},"modified":"2026-09-13T08:35:03","modified_gmt":"2026-09-13T06:35:03","slug":"analizar-la-carga-de-trabajo-de-softirq-en-linux-optimizacion-del-rendimiento-centro-de-datos","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/linux-softirq-auslastung-analysieren-performance-tuning-datacenter\/","title":{"rendered":"Analizar y optimizar la carga de los SoftIRQ en Linux"},"content":{"rendered":"<p>Te voy a explicar paso a paso c\u00f3mo <strong>SoftIRQ de Linux<\/strong>-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\u00e1s cortos <strong>Latencias<\/strong>, n\u00facleos de CPU equilibrados y un procesamiento de paquetes estable bajo una elevada carga de red.<\/p>\n\n<h2>Puntos centrales<\/h2>\n<ul>\n  <li><strong>Puntos de medici\u00f3n<\/strong> Comprender: \/proc\/softirqs, softnet_stat, interrupts<\/li>\n  <li><strong>S\u00edntomas<\/strong> Detectar: carga de ksoftirqd, p\u00e9rdida de paquetes, picos de latencia<\/li>\n  <li><strong>Sintonizaci\u00f3n<\/strong> controlar: netdev_budget y netdev_budget_usecs<\/li>\n  <li><strong>Distribuci\u00f3n<\/strong> Guardar: afinidad de IRQ, RSS, asignaci\u00f3n de colas<\/li>\n  <li><strong>Monitoreo<\/strong> Ejecutar: mpstat, perf, Tracing<\/li>\n<\/ul>\n\n<h2>Resumen de las SoftIRQ: c\u00f3mo funciona el n\u00facleo<\/h2>\n<p>Tras una interrupci\u00f3n de hardware, el n\u00facleo traslada parte del trabajo a los denominados <strong>SoftIRQs<\/strong>, para que las rutas cr\u00edticas se desocupan r\u00e1pidamente 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 <strong>Pila de red<\/strong>. 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\u00f3n prolongados de las SoftIRQ en algunos <strong>N\u00facleos<\/strong> 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\u00ed detecto cu\u00e1ndo las SoftIRQ se convierten en un cuello de botella y otras <strong>Optimizaciones<\/strong> son necesarios.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux-analyse-optimierung-5893.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Detectar los s\u00edntomas t\u00edpicos de una elevada carga de SoftIRQ<\/h2>\n<p>Lo primero que me indica una carga elevada de SoftIRQ es un nivel constantemente alto de <strong>CPU del n\u00facleo<\/strong> 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\u00f3n TLS o en un funcionamiento lento <strong>APIs<\/strong> se manifiesta. A menudo se acumulan las p\u00e9rdidas de paquetes, mientras que los anillos de la tarjeta de red se saturan y aumentan los atascos. Cuando las interrupciones est\u00e1n mal distribuidas, la CPU 0 suele verse muy afectada, ya que muchas l\u00edneas de IRQ, junto con el trabajo derivado, se concentran en una <strong>N\u00facleo<\/strong> aterrizar. Esta limitaci\u00f3n a un solo n\u00facleo aumenta los tiempos de espera de los servicios y reduce el rendimiento efectivo. Por eso estoy comprobando si se trata de un patr\u00f3n sistem\u00e1tico o si solo se debe a <strong>Picos<\/strong> conduce a.<\/p>\n\n<h2>Puntos clave de medici\u00f3n: c\u00f3mo interpretar correctamente \/proc y las herramientas<\/h2>\n<p>Empezar\u00e9 por \/proc\/softirqs, ya que all\u00ed puedo ver, por cada CPU y tipo, en qu\u00e9 medida, m\u00e1s o menos, <strong>NET_RX<\/strong>, NET_TX, TIMER o BLOCK. En \/proc\/net\/softnet_stat reviso las l\u00edneas prestando especial atenci\u00f3n a los campos que indican presupuestos no alcanzados o paquetes descartados, lo que, ante un aumento constante, indica claramente que <strong>Ciclos de sondeo<\/strong> indica. \/proc\/interrupts revela si las interrupciones de hardware se distribuyen de forma desigual entre las CPU y cu\u00e1les son las IRQ m\u00e1s activas. Herramientas como mpstat, top o htop me ayudan a identificar ksoftirqd\/cpuN y a determinar la distribuci\u00f3n de las <strong>Tiempos de Softirq<\/strong> evaluar por n\u00facleo. Si es necesario, perf proporciona puntos cr\u00edticos en la pila para que pueda identificar los manejadores y las rutas de los controladores que consumen m\u00e1s tiempo. La siguiente tabla resume los puntos de medici\u00f3n m\u00e1s importantes, los indicadores y los t\u00edpicos <strong>Acciones<\/strong> juntos.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Punto de medici\u00f3n<\/th>\n      <th>\u00c1mbitos e indicadores m\u00e1s importantes<\/th>\n      <th>interpretaci\u00f3n<\/th>\n      <th>Acci\u00f3n<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>\/proc\/softirqs<\/td>\n      <td>NET_RX, NET_TX, BLOCK por <strong>CPU<\/strong><\/td>\n      <td>Se aprecia una distribuci\u00f3n desigual de la carga<\/td>\n      <td>Ajustar la afinidad de IRQ, activar RSS<\/td>\n    <\/tr>\n    <tr>\n      <td>\/proc\/net\/softnet_stat<\/td>\n      <td>Contador de presupuesto\/ca\u00eddas, tercero <strong>Columna<\/strong><\/td>\n      <td>Los presupuestos son demasiado reducidos y los paquetes se quedan sin recoger<\/td>\n      <td>Aumentar netdev_budget\/usecs, comprobar RPS<\/td>\n    <\/tr>\n    <tr>\n      <td>\/proc\/interrupciones<\/td>\n      <td>L\u00edneas IRQ por <strong>CPU<\/strong>, asignaci\u00f3n de colas<\/td>\n      <td>Demasiadas IRQ en pocos n\u00facleos<\/td>\n      <td>Comprobar irqbalance, configurar smp_affinity<\/td>\n    <\/tr>\n    <tr>\n      <td>mpstat \/ perf<\/td>\n      <td>%soft, puntos de acceso, <strong>Pilas<\/strong><\/td>\n      <td>Se ven los nudos y las fibras dominantes<\/td>\n      <td>Dar prioridad al ajuste de los controladores y la pila<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Causas y patrones de carga elevada<\/h2>\n<p>Los picos suelen deberse a un nivel muy alto de <strong>Rendimiento<\/strong>, muchas conexiones paralelas o r\u00e1fagas UDP que dominan NET_RX. A veces, los valores predeterminados de los controladores prev\u00e9n lotes peque\u00f1os, lo que genera demasiadas interrupciones y sobrecarga a ksoftirqd, mientras que GRO\/LRO quedan sin utilizar <strong>sigue siendo<\/strong>. Las afinidades desfavorables concentran la carga de trabajo en la CPU 0, aunque habr\u00eda varias colas disponibles y el RSS podr\u00eda facilitar la distribuci\u00f3n. En las m\u00e1quinas virtuales, las vNIC sobrecargan el n\u00facleo del host, lo que aumenta los tiempos de SoftIRQ en el host a expensas de los invitados <strong>aumenta<\/strong>. Las superposiciones de contenedores a\u00f1aden paquetes adicionales a la pila, lo que hace que los flujos sencillos se conviertan de repente en rutas m\u00e1s complejas. Solo la combinaci\u00f3n de distribuci\u00f3n, presupuesto y <strong>Dosificaci\u00f3n<\/strong> Da como resultado una imagen completa.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux_softirq_meeting_8593.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Supervisi\u00f3n espec\u00edfica: hacer visibles las SoftIRQ<\/h2>\n<p>Para llevar a cabo un seguimiento eficaz, leo con regularidad <strong>\/proc<\/strong>-Selecciono las interfaces y las relaciono con m\u00e9tricas del host, como la carga y las latencias de programaci\u00f3n. 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. <strong>permanezca en<\/strong>. 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\u00f3n. Con perf record\/perf top a\u00edslo las rutas costosas, por ejemplo, las descargas de sumas de comprobaci\u00f3n, la fusi\u00f3n de GRO o <strong>qdisc<\/strong>-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\u00f3n de los controladores y los efectos de la programaci\u00f3n. De este modo, se obtiene una visi\u00f3n clara de la situaci\u00f3n a partir de m\u00e9tricas, cronolog\u00edas y <strong>Puntos de acceso<\/strong>.<\/p>\n\n<h2>Ajuste con netdev_budget y netdev_budget_usecs<\/h2>\n<p>Si la ruta NAPI es demasiado corta, la aumento poco a poco <strong>net.core.netdev_budget<\/strong> y net.core.netdev_budget_usecs, para procesar m\u00e1s 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 <strong>m\u00e1s corto<\/strong>. Aumento los valores de forma moderada, por ejemplo, de 300 a 600 paquetes y de 2000 a 4000 microsegundos, y compruebo si las dem\u00e1s 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\u00f3n <strong>acompa\u00f1a<\/strong>. Adem\u00e1s, conviene comprobar los valores de RPS\/RFS, GRO\/LRO y la MTU para aprovechar adecuadamente el agrupamiento de paquetes y el tama\u00f1o de los mismos. Para reducir las avalanchas de interrupciones, tengo en cuenta <a href=\"https:\/\/webhosting.de\/es\/interrupt-coalescing-optimizacion-de-la-red-serverflux\/\">Coalescencia de interrupciones<\/a> y ajusta los mismos detalles con los controladores NIC, si esta opci\u00f3n est\u00e1 disponible <strong>es<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux-softirq-analyse-optimierung-4738.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Optimizar la distribuci\u00f3n de interrupciones y la afinidad de IRQ<\/h2>\n<p>Para evitar cuellos de botella en un solo n\u00facleo, distribuyo las IRQ entre varios <strong>CPUs<\/strong>, ya sea mediante irqbalance o con m\u00e1scaras 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\u00facleo pueda trabajar con mayor facilidad <strong>lotes<\/strong> . Me aseguro de no mezclar las IRQ de control con las rutas de datos cr\u00edticas para preservar la localidad de la cach\u00e9 y la previsibilidad. Unas afinidades correctamente configuradas reducen las latencias y minimizan las p\u00e9rdidas, ya que el procesamiento posterior de las SoftIRQ ya no se queda atascado en un n\u00facleo <strong>sigue siendo<\/strong>. Los controladores suelen mostrar las asignaciones de colas a la CPU en sysfs; all\u00ed compruebo si cada cola tiene un n\u00facleo adecuado y si no se producen asimetr\u00edas. Para profundizar m\u00e1s, me gu\u00edo por gu\u00edas como <a href=\"https:\/\/webhosting.de\/es\/servidor-afinidad-irq-multinucleo-optimizacion-de-red-rendimiento\/\">Afinidad IRQ<\/a>, para tener en cuenta tambi\u00e9n los aspectos relacionados con NUMA y el efecto de la cach\u00e9 <strong>tener en cuenta<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux_softirq_optimierung_2793.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Gu\u00eda pr\u00e1ctica: De los s\u00edntomas a la soluci\u00f3n<\/h2>\n<p>Para empezar, compruebo los s\u00edntomas: ksoftirqd\/cpuN en \u00abtop\u00bb, porcentajes de SoftIRQ por n\u00facleo en <strong>mpstat<\/strong> y picos llamativos de NET_RX. A continuaci\u00f3n, recopilo datos concretos de \/proc\/softirqs, \/proc\/net\/softnet_stat y \/proc\/interrupts para identificar las rutas dominantes y las distribuciones desequilibradas. A continuaci\u00f3n, realizo peque\u00f1os ajustes, primero en los presupuestos de netdev, seguidos de la afinidad de IRQ y el RSS, en cada caso con un minucioso <strong>Controlar<\/strong>. Si siguen apareciendo p\u00e9rdidas de paquetes, compruebo la configuraci\u00f3n de los controladores, las opciones de coalescencia, las descargas y el comportamiento de GRO\/LRO. En hosts de m\u00e1quinas virtuales o contenedores, eval\u00fao adem\u00e1s c\u00f3mo interact\u00faan las vNIC con la pila del host f\u00edsico y d\u00f3nde se producen las <strong>Puntos de acceso<\/strong> realmente sea as\u00ed. Eval\u00fao cada cambio a trav\u00e9s de series temporales, hasta que las m\u00e9tricas y las latencias se estabilicen en un buen nivel <strong>terreno<\/strong>.<\/p>\n\n<h2>Buenas pr\u00e1cticas para un rendimiento sostenible<\/h2>\n<p>Voy a implementar un seguimiento peri\u00f3dico de los contadores SoftIRQ, ya que solo unos valores constantes <strong>Transparencia<\/strong> evita que se vuelvan a producir cuellos de botella. Las versiones actuales del n\u00facleo resultan muy \u00fatiles, ya que NAPI y Stack se siguen mejorando internamente, lo que proporciona reservas para situaciones dif\u00edciles <strong>Cargas<\/strong> crear. Es imprescindible mantener una distribuci\u00f3n equilibrada entre varios n\u00facleos, as\u00ed como contar con presupuestos razonables que recojan suficientes paquetes sin saturar el programador. Para perfiles de alojamiento con mucho tr\u00e1fico HTTPS y de API, merece la pena echar un vistazo a <a href=\"https:\/\/webhosting.de\/es\/softirq-cpu-hosting-red-rendimiento-optimizacion-datacenter\/\">SoftIRQ en el alojamiento web<\/a>, ya que ah\u00ed se pone de manifiesto hasta qu\u00e9 punto la elecci\u00f3n de las NIC, las colas y el ajuste mejoran la calidad del servicio. En la planificaci\u00f3n de la capacidad, tengo en cuenta los n\u00facleos de CPU, las caracter\u00edsticas de las NIC, la memoria y las zonas NUMA, para que haya reservas disponibles antes de <strong>Consejos<\/strong> llegar. De este modo, la plataforma sigue siendo resistente y responde correctamente a los picos estacionales o a los provocados por las campa\u00f1as <strong>Horas punta<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux_softirq_analyse_4839.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>softnet_stat en detalle: qu\u00e9 significan realmente las cifras<\/h2>\n<p>Para repasar de forma espec\u00edfica, leo <strong>\/proc\/net\/softnet_stat<\/strong> 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 <strong>tercera columna<\/strong> indica que hay presi\u00f3n de tiempo (en resumen: presupuesto o margen de tiempo insuficientes, NAPI debe interrumpirse). Si los \u00abdrops\u00bb o la presi\u00f3n 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\u00e1fagas solo aglomeran el trabajo a corto plazo; en ese caso, el procesamiento por lotes (GRO) suele ser m\u00e1s \u00fatil que los grandes presupuestos. Los kernels m\u00e1s recientes ampl\u00edan las estad\u00edsticas con campos para RPS\/RFS y l\u00edmites de flujo; si estos aumentan, distribuyo de forma m\u00e1s consciente a trav\u00e9s de RPS o reduzco RFS cuando sus consultas resultan m\u00e1s costosas que su beneficio. Siempre correlaciono los contadores con <strong>\/proc\/softirqs<\/strong>: Si NET_RX aumenta en n\u00facleos individuales junto con la presi\u00f3n de tiempo en softnet_stat, me centro primero en la distribuci\u00f3n (IRQ\/RSS) y, solo en un segundo momento, en presupuestos m\u00e1s amplios.<\/p>\n\n<h2>RPS\/RFS y XPS: control total de la gesti\u00f3n del software y el ajuste de colas<\/h2>\n<p>Si no hay RSS por hardware o este no es suficiente, configuro <strong>RPS<\/strong> (Receive Packet Steering), para distribuir la carga de recepci\u00f3n entre varios n\u00facleos. A trav\u00e9s de rps_cpus, asigno a las colas de recepci\u00f3n aquellos n\u00facleos que se ajustan a los trabajadores activos y, en la medida de lo posible, <strong>Cerca de NUMA<\/strong> est\u00e1n. En muchos flujos, a\u00f1ado <strong>RFS<\/strong> (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\u00e9, siempre y cuando las tablas de flujos no se conviertan en un cuello de botella. Por el lado del emisor, ayuda <strong>XPS<\/strong> (Transmit Packet Steering), la elecci\u00f3n de la cola de transmisi\u00f3n (TX) para adaptarla a la vinculaci\u00f3n de la aplicaci\u00f3n con la CPU. El objetivo es que un flujo se procese de forma coherente a trav\u00e9s de la misma cola de recepci\u00f3n\/transmisi\u00f3n (RX\/TX) y del mismo n\u00facleo, lo que reduce las latencias y <strong>GRO<\/strong>-Los lotes se hacen m\u00e1s grandes. Siempre pruebo las distribuciones por etapas: primero activo el RPS en unas pocas colas, mido el efecto (ca\u00eddas, %soft, latencias) y, a continuaci\u00f3n, a\u00f1ado el RFS\/XPS. Si los n\u00facleos se saturan debido al RPS o si empeora la tasa de aciertos de L3, vuelvo a reducir las m\u00e1scaras de CPU o vinculo las colas m\u00e1s estrechamente a los n\u00facleos de los servicios en cuesti\u00f3n.<\/p>\n\n<h2>NUMA, aislamiento de CPU e interacciones entre programadores<\/h2>\n<p>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 <strong>Dominio NUMA<\/strong> permanecen. En configuraciones con n\u00facleos dedicados en tiempo real o de baja latencia, los a\u00edslo mediante pol\u00edticas de CPU y Cgroup, y evito deliberadamente que las interrupciones SoftIRQ se ejecuten en ellos. <strong>ksoftirqd<\/strong> No deber\u00eda acabar en n\u00facleos aislados, ya que, de lo contrario, los paquetes se acumular\u00edan sin que nadie se diera cuenta. Por el contrario, los n\u00facleos aislados no deben quedarse totalmente sin atenci\u00f3n de IRQ cuando terminan rutas de datos: una clara afinidad y <strong>Servicio de limpieza<\/strong>- La estrategia es imprescindible. Para cargas de trabajo con SLO estrictos, evito prioridades SCHED_FIFO\/RR demasiado agresivas que podr\u00edan desplazar la ejecuci\u00f3n de NAPI. Superviso las longitudes de las colas de ejecuci\u00f3n, los despertares y las tasas de preeminencia: si los tiempos de SoftIRQ aumentan a medida que crece la interactividad de la aplicaci\u00f3n, ajusto la granularidad y las afinidades, en lugar de aumentar los presupuestos de forma generalizada.<\/p>\n\n<h2>qdisc, descargas y Busy-Poll: equilibrar la latencia y el rendimiento<\/h2>\n<p>En la ruta de salida, cada uno cuesta <strong>qdisc<\/strong>-Tiempo de CPU de la operaci\u00f3n. Elijo la disciplina que mejor se adapta al perfil: fq_codel ayuda a evitar el \u00abpuffer bloat\u00bb y suaviza los picos de tr\u00e1fico, mientras que <em>mq<\/em>-Variantes de tarjetas de red con colas m\u00faltiples. En el caso de un rendimiento de datos puro en enlaces estables, un qdisc m\u00e1s ligero puede minimizar los picos de latencia. En la entrada, merece la pena ajustar con precisi\u00f3n <strong>GRO\/TSO\/GSO<\/strong>: Los lotes m\u00e1s 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\u00f3n. Para rutas en las que la latencia es muy cr\u00edtica, configuro <strong>busy_poll<\/strong> y utilizo \u00abbusy_read\u00bb de forma moderada para extraer paquetes activamente del controlador, aunque solo bajo estrecha supervisi\u00f3n, para que otras tareas no se queden sin recursos. Del mismo modo, configuro <strong>Coalescencia de interrupciones<\/strong> En cuanto a los picos de tr\u00e1fico: 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\u00f3n. Es importante evaluar cada cambio por separado: los picos simulados, los picos reales de producci\u00f3n y los periodos de inactividad suelen presentar perfiles de latencia diferentes.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux-softirq-analyse-1934.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Lista de comprobaci\u00f3n para el diagn\u00f3stico y reversi\u00f3n segura<\/h2>\n<p>Sigo sistem\u00e1ticamente una breve lista de comprobaci\u00f3n para abordar los cambios: 1) Comprobar los s\u00edntomas (ksoftirqd, %soft, ca\u00eddas). 2) Comprobar la distribuci\u00f3n (\/proc\/interrupts, Queue-&gt;CPU, estado RSS\/RPS). 3) Ajustar los presupuestos, comprobar el efecto en <strong>softnet_stat<\/strong> Observar (la presi\u00f3n de tiempo disminuye, los \u00abdrops\u00bb se estancan). 4) Ajustar con precisi\u00f3n las descargas y la fusi\u00f3n, revisar el qdisc. 5) Verificar las asignaciones NUMA\/CPU y los cgroups. Cada paso termina con una mejora clara de las m\u00e9tricas o con el <strong>Rollback<\/strong> hasta el \u00faltimo estado \u00f3ptimo. Documento los valores objetivo y reales (latencia P95\/P99, %soft por n\u00facleo, tasas de ca\u00edda, cambios de contexto) para que las iteraciones posteriores no se realicen a ciegas. Si varias peque\u00f1as 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\u00f3neas y protege contra las espirales de optimizaci\u00f3n que, aunque aumentan las cifras de rendimiento, empeoran la interactividad y la estabilidad.<\/p>\n\n<h2>Separar claramente los casos l\u00edmite y los perfiles de carga de trabajo<\/h2>\n<p>Distingo deliberadamente entre transferencias masivas, API con latencia cr\u00edtica y tr\u00e1fico intermitente <strong>UDP<\/strong>-Tr\u00e1fico. Para datos masivos, recurro antes al procesamiento por lotes y a la fusi\u00f3n, siempre que no se produzcan p\u00e9rdidas de paquetes. En el tr\u00e1fico de API, doy prioridad a una distribuci\u00f3n uniforme, a lotes limitados y a latencias E2E estables, incluso si el rendimiento m\u00e1ximo nominal desciende ligeramente. Para combatir las r\u00e1fagas de UDP, prefiero recurrir a la ampliaci\u00f3n 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\u00f3n, preveo una carga adicional en la pila y distribuyo m\u00e1s ampliamente la carga de SoftIRQ. Adem\u00e1s, eval\u00fao por separado las sobrecargas del cortafuegos y de Conntrack: cuando las tablas alcanzan sus l\u00edmites, la carga de SoftIRQ aumenta inevitablemente, por muy buena que sea la distribuci\u00f3n de IRQ. Solo cuando las rutas por perfil son consistentemente ligeras, merece la pena ajustar con precisi\u00f3n los \u00faltimos porcentajes.<\/p>\n\n<h2>SoftIRQ en entornos de nube y contenedores<\/h2>\n<p>En entornos virtualizados, la carga se desplaza a trav\u00e9s de vSwitches, redes superpuestas y pilas de host, por lo que tengo que tener en cuenta tanto el entorno invitado como el host-<strong>M\u00e9tricas<\/strong> Anal\u00edzalo. Los tiempos elevados de SoftIRQ en el host ralentizan inmediatamente los contenedores y las m\u00e1quinas virtuales, incluso aunque los sistemas invitados parezcan funcionar sin problemas. <strong>trabajo<\/strong>. Por eso compruebo las descargas y la fusi\u00f3n en la tarjeta de red f\u00edsica, mientras que RPS\/RFS en el host distribuye mejor la ruta de software. Para las cargas de trabajo en contenedores, compruebo si los l\u00edmites de Cgroup para la CPU y el procesamiento de IRQ est\u00e1n configurados de forma adecuada, para que los servicios importantes no se vean afectados por <strong>Colas<\/strong> morir de hambre. Las vNIC compatibles con colas m\u00faltiples 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 <strong>Latencias<\/strong> y un rendimiento seguro y reproducible.<\/p>\n\n<h2>Resumen: Dominar con soltura el an\u00e1lisis de SoftIRQ<\/h2>\n<p>Quien analiza correctamente la carga de SoftIRQ, utiliza puntos de medici\u00f3n claros, examina las distribuciones y establece <strong>Pasos<\/strong>. Empiezo por \/proc\/softirqs y softnet_stat, establezco una correlaci\u00f3n con ksoftirqd y mpstat y, a partir de ah\u00ed, deduzco el orden de mis <strong>Medidas<\/strong>. Primero ajusto netdev_budget y netdev_budget_usecs; despu\u00e9s optimizo la afinidad de IRQ, el RSS y las opciones de procesamiento por lotes, como GRO y las descargas. Cada ajuste es m\u00ednimo, se mide y solo se mantiene si tiene un efecto positivo, hasta que desaparezcan las p\u00e9rdidas y <strong>Latencias<\/strong> 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\u00e1fico <strong>receptivo<\/strong>. De este modo, el rendimiento de Linux sigue siendo transparente, robusto y adaptable, sin que haya puntos cr\u00edticos ocultos que <strong>Estabilidad<\/strong> poner en peligro.<\/p>","protected":false},"excerpt":{"rendered":"<p>Descubre c\u00f3mo analizar y optimizar de forma sistem\u00e1tica la carga de SoftIRQ en Linux para mejorar el rendimiento de tus servidores mediante un ajuste espec\u00edfico de netdev y una mejor distribuci\u00f3n de las interrupciones.<\/p>","protected":false},"author":1,"featured_media":21340,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21347","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"96","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Linux SoftIRQ","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21340","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21347","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/comments?post=21347"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21347\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/21340"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=21347"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=21347"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=21347"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}