{"id":19569,"date":"2026-06-01T08:35:01","date_gmt":"2026-06-01T06:35:01","guid":{"rendered":"https:\/\/webhosting.de\/softirq-cpu-hosting-netzwerkdurchsatz-optimierung-datacenter\/"},"modified":"2026-06-01T08:35:01","modified_gmt":"2026-06-01T06:35:01","slug":"softirq-cpu-hosting-red-rendimiento-optimizacion-datacenter","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/softirq-cpu-hosting-netzwerkdurchsatz-optimierung-datacenter\/","title":{"rendered":"softirq cpu hosting: optimice el rendimiento del servidor y de la red"},"content":{"rendered":"<p>Muestro c\u00f3mo <strong>softirq cpu<\/strong> junto con NAPI, la distribuci\u00f3n de IRQ y el dise\u00f1o de colas limitan o liberan el rendimiento de la red en el alojamiento. Con puntos de medici\u00f3n claros, sintonizaci\u00f3n dirigida y afinidades limpias, reduzco <strong>Latencias<\/strong> y aumentar sistem\u00e1ticamente el rendimiento pps en los servidores productivos.<\/p>\n\n<h2>Puntos centrales<\/h2>\n<p>Estas ideas centrales transportan los paquetes de red de forma eficiente a trav\u00e9s de la CPU, el n\u00facleo y la NIC, y mantienen los tiempos de respuesta al m\u00ednimo. <strong>constante<\/strong> bajo.<\/p>\n<ul>\n  <li><strong>Presupuesto NAPI<\/strong> ajuste fino: M\u00e1s paquetes por sondeo reducen los gastos generales y suavizan el <strong>Carga de la CPU<\/strong>.<\/li>\n  <li><strong>Equilibrio de IRQ<\/strong> y afinidad: evitar puntos calientes, aumentar los aciertos de cach\u00e9, <strong>Picos de latencia<\/strong> Pulse.<\/li>\n  <li><strong>Cola m\u00faltiple<\/strong>, RSS\/RPS\/XPS: paralelizaci\u00f3n de flujos, mantenimiento de la alineaci\u00f3n NUMA, <strong>pps<\/strong> aumentar.<\/li>\n  <li><strong>Descarga<\/strong> utilizar conscientemente: GRO\/LRO, TSO, evaluar la coalescencia, <strong>Jitter<\/strong> vigilar.<\/li>\n  <li><strong>Aislamiento<\/strong> y Busy Polling: tiempos de respuesta predecibles en aplicaciones dedicadas. <strong>N\u00facleos<\/strong>.<\/li>\n<\/ul>\n\n<h2>Conceptos b\u00e1sicos: Qu\u00e9 ocurre en el n\u00facleo durante el tr\u00e1fico de red<\/h2>\n<p>Un paquete primero aterriza en una interrupci\u00f3n de hardware, despu\u00e9s de lo cual el n\u00facleo se hace cargo del trabajo en <strong>SoftIRQs<\/strong> y los bucles de sondeo NAPI. Me aseguro de que la fase r\u00e1pida HardIRQ sigue siendo muy corta y que la l\u00f3gica real se mueve al contexto correcto para que el <strong>tiempo de CPU<\/strong> no se agota. Los hilos ksoftirqd s\u00f3lo intervienen si no es posible el procesamiento directo, lo que conduce r\u00e1pidamente a colas bajo carga continua. Aqu\u00ed es exactamente donde se produce el tiempo de espera, que se refleja en un aumento del TTFB y un rendimiento fluctuante. Si quieres profundizar, puedes encontrar conocimientos pr\u00e1cticos sobre el procesamiento de IRQ en este art\u00edculo sobre <a href=\"https:\/\/webhosting.de\/es\/gestion-de-interrupciones-del-servidor-optimizacion-del-rendimiento-de-la-cpu-7342\/\">Gesti\u00f3n de interrupciones y rendimiento de la CPU<\/a>, que utilizo para la categorizaci\u00f3n.<\/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\/06\/serverperformance-netzwerk-4861.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NAPI, SoftIRQs y ksoftirqd: controlar la latencia en lugar de gestionarla<\/h2>\n<p>NAPI reduce las tormentas de interrupciones recogiendo varios paquetes por ejecuci\u00f3n dentro de un presupuesto definido y minimizando as\u00ed el tiempo de interrupci\u00f3n. <strong>Sobrecarga<\/strong> baja. Si el presupuesto es insuficiente, los paquetes se amontonan, el ksoftirqd se calienta y el <strong>Latencia<\/strong> aumenta de forma apreciable. En tales situaciones, compruebo sistem\u00e1ticamente \/proc\/softirqs y \/proc\/net\/softnet_stat para visualizar ca\u00eddas, time_squeeze o colas desbordadas. A continuaci\u00f3n, aumento gradualmente net.core.netdev_budget o net.core.netdev_budget_usecs y controlo en paralelo la carga de la CPU, la distribuci\u00f3n p95\/p99 y las p\u00e9rdidas de paquetes. El truco est\u00e1 en hacer suficiente trabajo por sondeo sin saturar la ejecuci\u00f3n interactiva de los hilos de usuario.<\/p>\n\n<h2>Equilibrio y afinidad de IRQ: evite los puntos calientes, aumente los aciertos de cach\u00e9.<\/h2>\n<p>Un \u00fanico n\u00facleo con todas las IRQs de la NIC se convierte en un cuello de botella porque tiene que servir interrupciones, IRQs suaves as\u00ed como hilos de aplicaciones; por lo tanto, distribuyo <strong>IRQs<\/strong> con objetivos concretos. El servicio irqbalance ayuda, pero para altas tasas de pps asigno expl\u00edcitamente colas RX\/TX mediante afinidad a colas adecuadas. <strong>n\u00facleos<\/strong>. En los sistemas NUMA, vinculo las colas a n\u00facleos del mismo nodo para evitar accesos remotos a la memoria. Los hilos de la aplicaci\u00f3n se ejecutan en n\u00facleos vecinos pero separados, lo que mejora la localizaci\u00f3n de la cach\u00e9 y la programabilidad. Esta gu\u00eda de distribuci\u00f3n estrat\u00e9gica ofrece una buena visi\u00f3n general de la <a href=\"https:\/\/webhosting.de\/es\/equilibrio-irq-del-servidor-optimizacion-del-rendimiento-de-la-red-centro-de-datos\/\">Equilibrio de IRQ en el centro de datos<\/a>, que utilizo como referencia para afinar.<\/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\/06\/serverperformance3942.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cola m\u00faltiple, RSS\/RPS\/XPS: uso correcto de la paralelizaci\u00f3n<\/h2>\n<p>Las NIC modernas vienen con varias colas RX\/TX, que puedo controlar mediante <strong>RSS<\/strong> a los flujos y lograr as\u00ed un paralelismo real. Si la tarjeta ofrece muy pocas colas, utilizo RPS\/XPS para realizar ajustes en el software con el fin de distribuir los paquetes de forma razonable entre los flujos. <strong>n\u00facleos<\/strong> para empujar. La distribuci\u00f3n limpia de hash es importante para que un flujo permanezca siempre en la misma CPU y no se produzcan costosas distorsiones de cach\u00e9. Al mismo tiempo, mantengo las rutas TX y RX cerca para evitar la contenci\u00f3n de bloqueos y accesos innecesarios entre nodos. Esto aumenta el rendimiento en pps sin que un solo n\u00facleo tire de los frenos.<\/p>\n\n<h2>Afinidad de la CPU hasta el espacio de usuario: pensamiento integral<\/h2>\n<p>Planifico la ruta de datos desde el NIC-IRQ a trav\u00e9s de las colas NAPI hasta los hilos worker de la app para que los paquetes lleguen a su destino sin enganches innecesarios y el <strong>Tiempo de respuesta<\/strong> permanece constante. Para conseguirlo, separo sistem\u00e1ticamente los n\u00facleos para interrupciones\/softIRQs de los n\u00facleos de aplicaci\u00f3n y creo n\u00facleos claros de <strong>Afinidad<\/strong>-reglas. A los servidores web, proxies inversos y bases de datos se les asignan conjuntos de CPU fijos que est\u00e1n cerca de los n\u00facleos IRQ para mantener las rutas cortas. Adem\u00e1s, establezco el gobernador de CPU en rendimiento para que los cambios de reloj no empujen el jitter a p99. Esta asignaci\u00f3n coherente hace que el comportamiento sea predecible y ayuda a diagnosticar los cuellos de botella de forma limpia.<\/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\/06\/server-performance-optimization-8321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Descargas, GRO\/LRO, cortafuegos y eBPF: ahorre carga sin ir a ciegas<\/h2>\n<p>Descarga de sumas de comprobaci\u00f3n, TSO y coalescencia <strong>tiempo de CPU<\/strong>, Sin embargo, pueden cambiar el tama\u00f1o de los paquetes, el comportamiento de las r\u00e1fagas y el jitter, que es por lo que mido los efectos espec\u00edficamente. GRO\/LRO agrupan las tramas y alivian la pila, pero para los requisitos en tiempo real decido seg\u00fan la situaci\u00f3n sobre <strong>Desactivaci\u00f3n<\/strong> o de uso limitado. Las tablas Conntrack y las profundas cadenas nftables\/iptables cuestan relojes, as\u00ed que ordeno las reglas superfluas y simplifico las rutas. Si es necesario, recurro a eBPF (XDP, tc-BPF) para tomar decisiones tempranas en el NIC y evitar rutas costosas. Un buen punto de partida para la pr\u00e1ctica del ajuste fino es este resumen de <a href=\"https:\/\/webhosting.de\/es\/interrupt-coalescing-optimizacion-de-la-red-serverflux\/\">Coalescencia de interrupciones<\/a>, que tengo en cuenta para los presupuestos sensibles a la latencia.<\/p>\n\n<h2>Polling ocupado y aislamiento de la CPU: bloqueo de los tiempos de respuesta<\/h2>\n<p>Para los objetivos de latencia dura, utilizo el sondeo ocupado para que los sockets del espacio de usuario recojan los paquetes incluso antes y <strong>Tiempos de espera<\/strong> acortar. Esto aumenta la carga, pero me proporciona p99 distribuciones muy estrechas para la API o el comercio de las cargas de trabajo en dedicado <strong>N\u00facleos<\/strong>. Adem\u00e1s, a\u00edslo los n\u00facleos con isolcpus=, nohz_full= y rcu_nocbs= para que los temporizadores, RCU y los servicios del sistema s\u00f3lo se ejecuten en las CPUs de mantenimiento. Esta separaci\u00f3n evita interferencias en los n\u00facleos de latencia y hace que el comportamiento sea reproducible. El resultado es una hoja de ruta clara: n\u00facleos dedicados, recogida temprana de paquetes, presupuestos definidos.<\/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\/06\/softirq_cpu_hosting_4321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Control y resoluci\u00f3n de problemas: del s\u00edntoma a la causa<\/h2>\n<p>Empiezo con los pps, el rendimiento y la carga del n\u00facleo, luego compruebo las ca\u00eddas y la actividad del <strong>ksoftirqd<\/strong>-hilos a lo largo del tiempo para reconocer patrones de forma fiable. Herramientas como sar, htop, ss, nload y ethtool me muestran cu\u00e1ndo y d\u00f3nde se produce la congesti\u00f3n y si la <strong>Cues<\/strong> alcanzan sus l\u00edmites. Las distribuciones son importantes en lugar de los valores medios para que no se pierdan los picos nocturnos, las ventanas cron o las campa\u00f1as. Correlaciono los picos de TTFB con la distribuci\u00f3n de IRQ, el presupuesto NAPI y los ajustes de descarga para realizar ajustes espec\u00edficos. Una afinidad IRQ ajustada o un nuevo presupuesto NAPI es a menudo suficiente para reducir notablemente los tiempos de espera.<\/p>\n\n<h2>Los par\u00e1metros de ajuste de un vistazo<\/h2>\n<p>El siguiente resumen me ayuda a utilizar los cambios con prudencia y a asignar los efectos con claridad antes de realizar cambios permanentes. <strong>lanzamientos<\/strong> plan. Pruebo cada ajuste de forma iterativa, mido las distribuciones de latencia y observo los efectos secundarios en <strong>CPU<\/strong> y la memoria. S\u00f3lo cambio un punto por ventana de prueba para que la causa y el efecto queden claros. Despu\u00e9s documento los resultados y establezco valores umbral para las alertas. De este modo, consigo mejoras reproducibles sin arriesgarme a sorpresas en el tr\u00e1fico productivo.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Par\u00e1metro\/Caracter\u00edstica<\/th>\n      <th>Efecto en la ruta de datos<\/th>\n      <th>Cu\u00e1ndo aumentar\/activar<\/th>\n      <th>Riesgos\/efectos secundarios<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>net.core.netdev_budget<\/strong><\/td>\n      <td>M\u00e1s paquetes por encuesta NAPI<\/td>\n      <td>Para gotas en softnet_stat<\/td>\n      <td>Las encuestas m\u00e1s largas desplazan a los hilos de usuarios<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>net.core.netdev_budget_usecs<\/strong><\/td>\n      <td>Limitar la ventana de tiempo por sondeo<\/td>\n      <td>Para fluctuaciones debidas a grandes r\u00e1fagas<\/td>\n      <td>Demasiado peque\u00f1o: m\u00e1s cambios de contexto<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>RSS\/RPS\/XPS<\/strong><\/td>\n      <td>Distribuir flujos entre n\u00facleos<\/td>\n      <td>Para puntos calientes en un n\u00facleo<\/td>\n      <td>Hashes incorrectos: distorsiones de cach\u00e9<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Afinidad IRQ<\/strong><\/td>\n      <td>Vincular IRQs cerca del n\u00facleo<\/td>\n      <td>Con NUMA-Missmatch<\/td>\n      <td>La mala asignaci\u00f3n crea nuevos puntos calientes<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>GRO\/LRO\/TSO<\/strong><\/td>\n      <td>Reduce el n\u00famero de paquetes<\/td>\n      <td>Para el cuello de botella de la CPU<\/td>\n      <td>Jitter, r\u00e1fagas m\u00e1s grandes<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Sondeo ocupado<\/strong><\/td>\n      <td>Recogida anticipada de paquetes<\/td>\n      <td>Para objetivos dif\u00edciles de p99<\/td>\n      <td>M\u00e1s consumo de CPU<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\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\/06\/developer_desk_focus_optimization_3748.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Anillos RX\/TX y profundidad de cue: dimensiona correctamente los buffers<\/h2>\n<p>Incluso con IRQ bien distribuidas y presupuestos adecuados, los anillos de NIC demasiado peque\u00f1os o demasiado grandes pueden mermar el rendimiento. Por ello, compruebo los tama\u00f1os de anillo RX\/TX de la tarjeta y los adapto a los objetivos de car\u00e1cter de r\u00e1faga y latencia. Los anillos demasiado peque\u00f1os provocan ca\u00eddas en la NIC durante los picos de tr\u00e1fico, visibles como rx_missed_errors o fifo_errors en las estad\u00edsticas del controlador. Los anillos demasiado grandes ocultan la congesti\u00f3n, aumentan la latencia y crean largos bordes de fuga en p95\/p99. Busco el t\u00e9rmino medio: suficiente b\u00fafer para absorber r\u00e1fagas cortas, pero no tanto como para que los paquetes \u201cenvejezcan\u201d en las colas.<\/p>\n<p>Adem\u00e1s, miro el host-side <strong>tx_queue_len<\/strong> y el Qdisc utilizado. Con sch_fq o fq_codel, puedo suavizar el comportamiento de las r\u00e1fagas y distribuir grandes paquetes TSO mediante pacing. Esto reduce las microrr\u00e1fagas en el puerto del conmutador y suaviza la curva de latencia, algo importante para las cargas de trabajo mixtas en las que se ejecutan peque\u00f1as RPC junto con grandes cargas. Superviso las estad\u00edsticas ethtool y las correlaciono con softnet_stat para reconocer si la congesti\u00f3n se produce en el anillo NIC, en el backlog netdev o en el Qdisc.<\/p>\n\n<h2>MTU, tramas jumbo y segmentaci\u00f3n<\/h2>\n<p>El <strong>MTU<\/strong> es una palanca cl\u00e1sica que a menudo se subestima. Las tramas jumbo reducen el n\u00famero de paquetes por Gbit\/s y reducen la carga de la CPU, pero s\u00f3lo si la ruta es realmente apta para jumbo de extremo a extremo. Por eso, valido sistem\u00e1ticamente las estaciones remotas, los conmutadores y los t\u00faneles. En cuanto hay fragmentaci\u00f3n de vuelta a 1500 en alguna parte, hay riesgo de problemas de MTU de ruta, retransmisiones e innecesarias <strong>Jitter<\/strong>. En los centros de datos con comunicaci\u00f3n Este\/Oeste dominante, merece la pena una estrategia 9k homog\u00e9nea, mientras que 1500 suele ser la opci\u00f3n m\u00e1s estable para las cargas de trabajo orientadas a Internet.<\/p>\n<p>Siempre eval\u00fao la MTU junto con <strong>TSO\/GSO\/GRO<\/strong>Un agrupamiento demasiado agresivo puede dar lugar a grandes r\u00e1fagas en el TX que llenen los b\u00faferes de subida y generen picos de latencia. El objetivo es una ruta coherente: segmentaci\u00f3n sensata en el transmisor, mecanismos de ritmo suficientes y GRO que ahorre trabajo en el lado del receptor sin frustrar los requisitos de tiempo real.<\/p>\n\n<h2>UDP, QUIC y cargas de trabajo de streaming: consideraciones espec\u00edficas<\/h2>\n<p>No todo el tr\u00e1fico es TCP. <strong>UDP<\/strong>-Los perfiles pesados (DNS, VoIP, QUIC, telemetr\u00eda) se comportan de forma diferente en RSS\/RPS y GRO. Las pilas modernas admiten UDP-GRO\/GSO, que puede reducir la carga de la CPU: yo lo utilizo de forma selectiva y mido si aumentan los riesgos de reordenaci\u00f3n o el jitter. Para cargas QUIC\/HTTP3, la distribuci\u00f3n limpia de flujos es crucial: RPS puede ayudar si la NIC ofrece muy pocas colas RSS, pero no debe \u201ctirar\u201d ning\u00fan flujo de cach\u00e9 caliente. En el lado TX configuro <strong>XPS<\/strong> para agrupar las rutas de transmisi\u00f3n y reducir la contenci\u00f3n de bloqueos. En la pr\u00e1ctica, una asignaci\u00f3n silenciosa y af\u00edn al n\u00facleo merece la pena, especialmente con muchos flujos UDP de tama\u00f1o medio en los que cada golpe de cach\u00e9 cuenta.<\/p>\n\n<h2>Virtualizaci\u00f3n y contenedores: integraci\u00f3n limpia de host, guest y vhost<\/h2>\n<p>En entornos virtualizados, el trabajo cambia entre el host, los hilos del vhost y las IRQ del hu\u00e9sped. Me aseguro de que <strong>vhost-net<\/strong>-threads reciben sus propios n\u00facleos y no colisionan con app workers. Sus afinidades deben coincidir con las colas RX\/TX f\u00edsicas, de lo contrario se producir\u00e1 una migraci\u00f3n innecesaria entre CPU. En el hu\u00e9sped, compruebo las colas de virtio-net, activo las colas m\u00faltiples y configuro RSS\/RPS de forma an\u00e1loga a bare metal. Donde la latencia y los pps est\u00e1n en primer plano <strong>SR-IOV<\/strong> reducir a\u00fan m\u00e1s los gastos generales - el requisito previo es una topolog\u00eda NUMA coherente: VF, vCPU y memoria pertenecen al mismo nodo.<\/p>\n<p>En la pila de contenedores, las redes superpuestas, las cadenas NAT profundas y las topolog\u00edas CNI complejas provocan saltos adicionales. Para los servicios de latencia cr\u00edtica, prefiero hostNetwork o redes magras (macvlan\/ipvlan), igualar las rutas NAT y mantener <strong>Conntrack<\/strong> lo m\u00e1s peque\u00f1o posible. Es importante una estrategia de CPU coherente: los n\u00facleos IRQ y NAPI del host deben estar situados en la vecindad de los n\u00facleos en los que se ejecutan los vhost\/container workers - es la \u00fanica forma de mantener la ruta de datos corta y predecible.<\/p>\n\n<h2>Programaci\u00f3n, estados C y subprocesos IRQ<\/h2>\n<p>Porque la latencia no es s\u00f3lo tiempo de c\u00e1lculo, sino tambi\u00e9n <strong>Hora de despertarse<\/strong> Minimizo los estados C profundos en los n\u00facleos de latencia. Un powersave agresivo puede costar milisegundos antes de que se ejecute una SoftIRQ. Por tanto, conf\u00edo en los reguladores de rendimiento, limito los estados C profundos y mantengo el turbo consistente para que los saltos de frecuencia sean predecibles. Igualmente importante es <strong>Enhebrado IRQ<\/strong>Cuando los controladores lo permiten, muevo el trabajo a los hilos IRQ y priorizo para que RX se inicie antes que el trabajo posterior sin desplazar completamente a userland. La interacci\u00f3n de las pol\u00edticas de programaci\u00f3n, afinidades y presupuestos es complicada; pruebo paso a paso, registro p99 y vigilo las interferencias con ksoftirqd, que de lo contrario se convierte en un cuello de botella secreto.<\/p>\n\n<h2>Observaci\u00f3n en profundidad: tracepoints, contadores, histos<\/h2>\n<p>Si las m\u00e9tricas siguen siendo imprecisas, voy un nivel m\u00e1s all\u00e1: utilizo tracepuntos del n\u00facleo en torno a <strong>netif_receive_skb<\/strong>, <strong>napi_poll<\/strong> y <strong>net_dev_queue<\/strong>, para ver la duraci\u00f3n de los sondeos, la cantidad de paquetes y los tiempos de espera en forma de histogramas. Estas distribuciones muestran si 1 % de los sondeos est\u00e1n tardando demasiado o si se est\u00e1n agotando las colas individuales. Adem\u00e1s, ethtool-<strong>rx\/tx<\/strong>-counters, TCP retransmits, busy poll hits y softnet_stat indican claramente d\u00f3nde se est\u00e1n perdiendo paquetes. Utilizo el an\u00e1lisis de ca\u00eddas para reconocer si la NIC se est\u00e1 cayendo (anillo lleno), el backlog de netdev se est\u00e1 colapsando (time_squeeze) o el Qdisc\/firewall se est\u00e1 ralentizando. S\u00f3lo cuando estas piezas del rompecabezas encajan, ajusto los anillos, los presupuestos o las descargas.<\/p>\n\n<h2>Racionalice las v\u00edas de seguridad y filtrado<\/h2>\n<p>ACLs complejas, cadenas nftables\/iptables profundas y amplias tablas conntrack a\u00f1aden latencia constante por paquete. Yo consolido reglas, trabajo con conjuntos\/mapas y muevo las ca\u00eddas gen\u00e9ricas lo m\u00e1s adelante posible en la ruta - idealmente tan pronto como sea posible en la NIC (XDP\/clsact) si la latencia es cr\u00edtica. Los flujos sin estado, la telemetr\u00eda o los puertos \u201cseguros\u201d conocidos pueden utilizarse de forma selectiva. <strong>sin seguimiento<\/strong> para eliminar la necesidad de costosas b\u00fasquedas. Al mismo tiempo, mantengo las tablas de estado actualizadas, ajusto los tama\u00f1os hash a los picos de carga y ordeno agresivamente las entradas hu\u00e9rfanas. El objetivo es una ruta de pol\u00edtica limpia y rastreable que no se note en el perfil como una carga permanente.<\/p>\n\n<h2>Antipatrones t\u00edpicos y c\u00f3mo los evito<\/h2>\n<ul>\n  <li><strong>Todas las IRQ en un n\u00facleo:<\/strong> conduce a la congesti\u00f3n y ksoftirqd caliente. Ant\u00eddoto: afinidades dirigidas por taco, coherentes con NUMA.<\/li>\n  <li><strong>Maximizaci\u00f3n ciega de anillos\/presupuestos:<\/strong> oculta la congesti\u00f3n, aumenta las colas de latencia. Ant\u00eddoto: aumentar gradualmente, medir las distribuciones.<\/li>\n  <li><strong>Configuraci\u00f3n incorrecta del hash de flujo:<\/strong> Los flujos saltan entre n\u00facleos, las cach\u00e9s se desvanecen. Ant\u00eddoto: claves RSS estables, RPS\/XPS s\u00f3lo con un objetivo claro.<\/li>\n  <li><strong>Hilos de aplicaci\u00f3n en los mismos n\u00facleos que SoftIRQs:<\/strong> Interferencias y fluctuaciones. Ant\u00eddoto: separaci\u00f3n dura, asignaci\u00f3n por vecinos.<\/li>\n  <li><strong>Overlays\/NAT sin presupuesto:<\/strong> a cada salto. Soluci\u00f3n: racionalice las rutas y aloje redes para cargas de trabajo con latencia.<\/li>\n  <li><strong>Ahorro de energ\u00eda en los n\u00facleos de latencia:<\/strong> Los estados C profundos ralentizan la reacci\u00f3n. Ant\u00eddoto: regulador de rendimiento, limitaci\u00f3n del estado C.<\/li>\n  <li><strong>Descarga sin medici\u00f3n:<\/strong> TSO\/GRO puede exacerbar las r\u00e1fagas y las fluctuaciones. Remedio: Activar carga de trabajo espec\u00edfica, monitorizar p99.<\/li>\n<\/ul>\n\n<h2>Acogida pr\u00e1ctica: pasos que funcionan<\/h2>\n<p>Empiezo con una fase de medici\u00f3n limpia, establezco l\u00edneas de base y mantengo todos los cambios peque\u00f1os en ventanas de tiempo cortas para poder <strong>Causas<\/strong> pueden separarse. A continuaci\u00f3n, activo irqbalance, compruebo la distribuci\u00f3n autom\u00e1tica y, si es necesario, establezco afinidades manuales hasta que no haya <strong>Puntos de acceso<\/strong> ya no son visibles. A continuaci\u00f3n, configuro Multi-Queue, RSS y, si es necesario, RPS\/XPS, sincronizados con NUMA. Vinculo los app workers a n\u00facleos cercanos a sus n\u00facleos IRQ, pero sin colisi\u00f3n directa. Por \u00faltimo, purgo las rutas del cortafuegos, compruebo las tablas conntrack y tomo decisiones conscientes sobre las descargas basadas en objetivos de latencia.<\/p>\n\n<h2>Ejemplo de libro de jugadas para p99 latencias<\/h2>\n<p>Primero mido p95\/p99 mediante carga representativa y aseguro los logs de \/proc\/softirqs y \/proc\/net\/softnet_stat para <strong>Gotas<\/strong> y time_squeeze son claramente visibles. A continuaci\u00f3n, aumentar netdev_budget o netdev_budget_usecs paso a paso y mantenga p99 despu\u00e9s de cada cambio para que pueda ver real <strong>Tendencias<\/strong> reconocer. Paralelamente, asocio IRQs a los n\u00facleos de un nodo NUMA y muevo los app workers a los vecinos adecuados. Si p99 sigue saltando, pruebo variantes de GRO\/LRO y perfiles de coalescencia de interrupciones, cada uno con una ruta de medici\u00f3n corta. S\u00f3lo cuando la distribuci\u00f3n permanece estable transfiero la configuraci\u00f3n a roles Ansible o dropins systemd.<\/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\/06\/serverraum-performance-1947.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Versi\u00f3n corta para administradores<\/h2>\n<p>Logro el mayor efecto multiplicador <strong>SoftIRQs<\/strong>, Presupuesto NAPI, afinidades IRQ e hilos de aplicaci\u00f3n como una ruta de datos coherente. Distribuyo el trabajo de red entre los n\u00facleos, mantengo colas coherentes con NUMA y conecto los trabajadores de forma sensata para que <strong>Rutas<\/strong> ser breve. Configuro las descargas deliberadamente y mido el jitter en lugar de optimizar ciegamente el rendimiento. Para los objetivos de latencia dif\u00edciles, conf\u00edo en el sondeo ocupado y el aislamiento de la CPU, mientras que las CPU de mantenimiento interceptan las interferencias. Si se aplican estos pasos de forma disciplinada, se obtiene un rendimiento constante, distribuciones de latencia m\u00e1s estrechas y un entorno de alojamiento que reacciona de forma predecible a los picos de carga.<\/p>","protected":false},"excerpt":{"rendered":"<p>Descubra c\u00f3mo el alojamiento de cpu softirq con interrupciones linux optimizadas, NAPI y equilibrio IRQ aumenta el rendimiento de su red y reduce las latencias en el funcionamiento del servidor.<\/p>","protected":false},"author":1,"featured_media":19562,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-19569","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":"65","_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":"softirq cpu","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":"19562","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/19569","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=19569"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/19569\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/19562"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=19569"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=19569"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=19569"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}