Ir al contenido 
La alta carga de la red viene determinada por el procesamiento eficiente de IRQ del servidor señales: Si distribuyes las interrupciones sabiamente entre los núcleos de la CPU, reduces la latencia y evitas caídas. En esta guía, te mostraré cómo combinar el equilibrio de IRQ, RSS/RPS y la afinidad de CPU de forma práctica para hacer sostenible el alojamiento de alta carga. performante para operar.
Puntos centrales
- Distribución IRQ evita puntos calientes en núcleos de CPU individuales.
- Cola múltiple más RSS/RPS paraleliza el procesamiento de paquetes.
- Atención NUMA reduce el acceso entre nodos y la latencia.
- Gobernador de CPU y la fijación de hilos suavizan los tiempos de respuesta.
- Monitoreo Comprueba pps, latencias, caídas y utilización del núcleo.
Las IRQ explicadas brevemente: por qué controlan la carga de la red
Para cada paquete entrante, la tarjeta de red informa a través de IRQ, que el trabajo está pendiente, de lo contrario el núcleo tendría que sondear activamente. Si la asignación permanece en un núcleo, su utilización aumenta, mientras que otros núcleos sin usar permanecen. Este es exactamente el momento en que crecen las latencias, se llenan los búferes del anillo RX y los controladores empiezan a descartar paquetes. Distribuyo las interrupciones entre los núcleos adecuados para mantener el procesamiento de paquetes uniforme y predecible. Esto alivia los cuellos de botella, suaviza los tiempos de respuesta y mantiene las pérdidas de paquetes al mínimo.
Equilibrio de IRQ y afinidad de CPU en Linux
El servicio irqbalance distribuye las interrupciones dinámicamente, analiza la carga y desplaza las afinidades automáticamente a lo largo del tiempo. Para perfiles de carga extremos, defino las afinidades manualmente mediante /proc/irq//smp_affinity y se unen específicamente a núcleos del mismo NUMA-nodos. Esta combinación de automatismo y ajuste fino me ayuda a procesar limpiamente tanto las cargas base como los picos. Una introducción en profundidad a Gestión de interrupciones y optimización de la CPU Las utilizo para ayudarme en mi planificación. Sigue siendo importante: Siempre relaciono la topología del hardware, la distribución de IRQ y los hilos de aplicación entre sí.
Uso práctico de NIC multicola, RSS y RPS
Las NIC modernas proporcionan varias colas de RX/TX, cada cola activa su propia IRQs, y Receive Side Scaling (RSS) distribuye los flujos entre los núcleos. Si no hay suficientes colas de hardware, añado Receive Packet Steering (RPS) y Transmit Packet Steering (XPS) al kernel para disponer de más Paralelismo. Con ethtool -L ethX combinado N Ajusto el número de cola al número de núcleo del nodo NUMA asociado. Compruebo con ethtool -S y nstat, si se producen caídas, sondeos ocupados o picos altos de pps. Para una suavización más fina de la carga, también utilizo Coalescencia de interrupciones en la planificación para que la NIC no genere demasiadas IRQ individuales.
La siguiente tabla muestra los componentes centrales y los comandos típicos que utilizo para una configuración coherente:
| Bloque de construcción | Objetivo | Ejemplo | Nota |
|---|---|---|---|
| irqbalance | Distribución automática | systemctl enable --now irqbalance | Punto de partida para cargas de trabajo mixtas |
| Afinidad | Arregla la fijación | echo mask > /proc/irq/XX/smp_affinity | Observar la asignación NUMA |
| Cues | Más paralelismo | ethtool -L ethX combinado N | Coincidencia con los núcleos de los nodos |
| RSS/RPS | Distribución del caudal | sysfs: rps_cpus/rps_flow_cnt | Útil para un pequeño número de colas NIC |
| XPS | Núcleos de ruta TX ordenados | sysfs: xps_cpus | Evita el colapso de la caché |
Uso razonable del equilibrio automático de IRQ
En el caso de los servidores de alojamiento mixtos, suele bastar con activar irqbalance, porque el demonio reconoce constantemente los cambios de carga. Compruebo el estado mediante systemctl status irqbalance y eche un vistazo a /proc/interrupciones, para ver la distribución por cola y núcleo. Si las latencias aumentan en picos, defino núcleos de prueba que procesen principalmente interrupciones y comparo los valores medidos antes y después del cambio. Mantengo la configuración simple, para que las auditorías posteriores y las reversiones sean rápidas. Solo cuando los patrones están claros profundizo en la fijación.
Afinidad manual de la CPU para un control máximo
A tasas de pps muy altas, conecto colas de RX a núcleos seleccionados del mismo NUMA-y separo deliberadamente los hilos de aplicación de ellos. Aíslo los núcleos individuales para las interrupciones, ejecuto los trabajadores en núcleos vecinos y presto una atención estricta a la localización de la caché. De este modo, reduzco los accesos entre nodos y minimizo los costosos cambios de contexto en la ruta caliente. Para obtener resultados reproducibles, documento claramente las máscaras IRQ, la asignación de colas y la afinidad de hilos de los servicios. Esta claridad mantiene los tiempos de ejecución de los paquetes constante y reduce los valores atípicos.
Coordinación limpia de la optimización de la CPU y las aplicaciones
Puse el Gobernador de CPU a menudo se establece en „rendimiento“ porque los cambios de reloj aumentan los saltos de latencia. Vinculo procesos críticos como Nginx, HAProxy o bases de datos a núcleos que están cerca de los núcleos IRQ, o los separo deliberadamente si el perfil de caché lo requiere. Sigue siendo importante limitar los cambios de contexto y mantener el núcleo actualizado para que las optimizaciones de la pila de red surtan efecto. Mido los efectos de cada cambio en lugar de hacer suposiciones y me adapto paso a paso. El resultado es una configuración que funciona bajo carga previsible reacciona.
Configurar correctamente el seguimiento y la medición
Sin valores medidos, el ajuste sigue siendo un juego de adivinanzas, así que empezaré con sar, mpstat, vmstat, nstat, ss y ethtool -S. Para las pruebas de carga estructuradas utilizo iperf3 y observo el rendimiento, los pps, la latencia, las retransmisiones y la utilización del núcleo. Registro tendencias a largo plazo utilizando sistemas de monitorización estándar para reconocer patrones como picos vespertinos, ventanas de backup o campañas. Si quiere comprender la ruta de datos de forma holística, se beneficia de una visión del Proceso de paquetes de la IRQ de la NIC al espacio de usuario. Sólo la combinación de estas señales muestra si el equilibrio de IRQ y la afinidad han logrado el efecto deseado. Efecto traer.
Entender NAPI, Softirqs y ksoftirqd
Para gestionar los picos de latencia con cargas de pps elevadas, tengo en cuenta la NAPI-mecánica y la interacción de IRQs duras e IRQs blandas. Después de la primera IRQ hardware, NAPI recupera varios paquetes de la cola de RX en modo de sondeo para evitar tormentas de IRQs. Si las IRQs blandas no se procesan con prontitud, se mueven a ksoftirqd/N Hilos que sólo se ejecutan con prioridad normal - una razón clásica para aumentar las latencias de cola. Observo /proc/softirqs y /proc/net/softnet_stat; un alto „tiempo_apretado“ o caídas indican que el presupuesto es demasiado ajustado. Con sysctl -w net.core.netdev_budget_usecs=8000 y sysctl -w net.core.netdev_budget=600 Aumento el tiempo de procesamiento por sondeo NIC y el presupuesto de paquetes como prueba. Importante: Aumento los valores gradualmente, mido y compruebo si se producen fluctuaciones de la CPU o interferencias con los hilos de la aplicación.
Ajuste del hash RSS y de la tabla de indirecciones
RSS distribuye los flujos a las colas a través de la tabla de indirección (RETA). Verifico la clave hash y la tabla con ethtool -n ethX rx-flow-hash tcp4 y establecer la distribución simétrica si es necesario. Con ethtool -X ethX igual N o específicamente por entrada (ethtool -X ethX hkey ... hfunc toeplitz indir 0:1 1:3 ...), hago coincidir las asignaciones con los núcleos preferidos de un nodo NUMA. El objetivo es Adherencia del flujoUn flujo permanece en el mismo núcleo para que la localidad de la caché y la retención de bloqueos en la pila sean mínimas. Para entornos con muchos flujos UDP cortos, aumento rps_flow_cnt por cola de RX para que la distribución de software tenga suficientes cubos y no cree ningún hotspot. Tengo en cuenta que los hashes simétricos ayudan con las topologías ECMP, pero en el contexto del servidor, el equilibrio de núcleos es lo que más cuenta.
Elija las descargas, GRO/LRO y tamaños de anillos con sensatez
Las descargas de hardware reducen la carga de la CPU, pero pueden cambiar los perfiles de latencia. Lo compruebo con ethtool -k ethX, si TSO/GSO/UDP_SEG en TX y GRO/LRO están activas en RX. GRO agrupa paquetes en el núcleo y casi siempre es útil para el rendimiento; LRO puede ser problemático en configuraciones de enrutamiento o filtrado y es mejor dejarlo desactivado allí. Para APIs de latencia crítica, pruebo una agregación GRO más pequeña (o temporalmente desactivada) si dominan las latencias p99. También ajusto el tamaño de los anillos mediante ethtool -G ethX rx 1024 tx 1024: Los anillos más grandes interceptan las ráfagas, pero aumentan la latencia en caso de congestión; los anillos demasiado pequeños provocan rx_missed_errors. Me baso en valores medidos de ethtool -S (por ejemplo. rx_no_buffer_count, rx_dropped) y acordar esto con BQL (límites de cola de bytes, automáticos en el lado del núcleo) para que las colas de TX no se sobrecarguen.
Virtualización: IRQs en VMs y en el hipervisor
En configuraciones virtualizadas, controlo la distribución de NIC físicas en el host y configuro Equilibrio de IRQ claramente. Las máquinas virtuales obtienen suficientes vCPU, pero evito el sobrecompromiso ciego para que los retrasos en la programación no aumenten la latencia. Los controladores paravirtualizados modernos como virtio-net o vmxnet3 me proporcionan las mejores rutas para altas tasas de pps. Dentro de la máquina virtual, vuelvo a comprobar la afinidad y el recuento de colas para que el invitado no se convierta en un cuello de botella. Es crucial tener una visión coherente del host y del invitado para que toda la ruta de datos verdadero.
Profundizar en la virtualización: SR-IOV, vhost y OVS
Para tasas de pps muy altas, utilizo el hipervisor SR-IOVVinculo funciones virtuales (VF) de la NIC física directamente a las máquinas virtuales y las conecto a los núcleos de los nodos NUMA correspondientes. Esto evita partes de la pila del host y reduce la latencia. Cuando SR-IOV no encaja, presto atención a vhost-net y fijar los subprocesos vhost, como los trabajadores de aplicaciones y los núcleos IRQ, para que no se produzcan saltos cross-NUMA. En configuraciones de superposición o conmutación, evalúo los costes adicionales de Linux bridge u OVS; para perfiles extremos, sólo utilizo OVS-DPDK si el esfuerzo operativo justifica la ventaja medible. Lo mismo se aplica aquí: mido los pps, la latencia y la distribución de la CPU antes de tomar decisiones, no después.
Sondeo de ocupación y ajuste del espacio de usuario
Para servicios de latencia crítica Sondeo ocupado reducir el jitter. Activo lo siguiente como prueba sysctl -w net.core.busy_read=50 y net.core.busy_poll=50 (microsegundos) y configure la opción de socket SO_BUSY_POLL selectivamente para los sockets afectados. El espacio de usuario entonces sondea poco antes de bloquear y captura los paquetes antes de que se muevan más profundamente en las colas. Esto cuesta tiempo de CPU, pero a menudo ofrece latencias p99 más estables. Mantengo los valores bajos, controlo la utilización del núcleo y sólo combino el sondeo ocupado con una clara afinidad de hilos y un gobernador de CPU fijo, de lo contrario los efectos se anulan mutuamente.
Costes de filtro de paquetes, Conntrack y eBPF de un vistazo
El cortafuegos y NAT forman parte de la ruta de datos. Por lo tanto, compruebo el nftables/iptables-reglas y ordeno las reglas muertas o las cadenas profundas. En configuraciones con mucho trabajo, ajusto el tamaño de la tabla Conntrack (nf_conntrack_max, ) o desactivar Conntrack específicamente para flujos sin estado. Si se utilizan programas eBPF (XDP, tc-BPF), mido sus costes de tiempo de ejecución por gancho y doy prioridad a „early drop/redirect“ para aliviar las rutas caras. Es importante tener clara la responsabilidad: la optimización tiene efecto en la descarga NIC, en el programa eBPF o en la pila clásica - la duplicación sólo aumenta la latencia.
Aislamiento de la CPU y núcleos de mantenimiento
Para una latencia absolutamente determinista, almaceno trabajo de fondo en CPUs de mantenimiento off. Parámetros del núcleo como nohz_full=, rcu_nocbs= y irqaffinity= ayudan a mantener los núcleos dedicados en gran medida libres del manejo de ticks, callbacks de RCU e IRQs externas. Aíslo un conjunto de núcleos para los trabajadores de la aplicación y otro para las IRQ y las softirq; los servicios del sistema y los temporizadores se ejecutan en núcleos separados. Esto garantiza perfiles de caché limpios y reduce los efectos de tanteo. Hyper-threading puede aumentar el jitter en casos individuales; pruebo si desactivarlo por par de núcleos suaviza las latencias p99 antes de tomar una decisión global.
Manual de diagnóstico y antipatrones típicos
Cuando se producen caídas o picos de latencia, adopto un enfoque estructurado: 1) /proc/interrupciones Compruebe si la distribución es desigual. 2) ethtool -S en caídas RX/TX, errores FIFO, rx_no_buffer_count comprobar. 3) /proc/net/softnet_stat a „tiempo_apretado" o "gotas“. 4) mpstat -P TODOS y top para la actividad de ksoftirqd. 5) Métricas de aplicación (número de conexiones activas, retransmisiones con ss -ti). Antimodelos que evito: anillos RX enormes (congestión oculta), activación/desactivación salvaje de descargas sin medición, mezcla de afinidades fijas con irqbalance agresivo, o RPS y RSS simultáneamente sin una arquitectura objetivo clara. Cada cambio recibe una medición antes/después de la comparación y un breve protocolo.
Ejemplos de conceptos de alojamiento web y API
Servidor de alojamiento web clásico
Para muchos sitios web pequeños activo irqbalance, Configuro varias colas y selecciono el gobernador de rendimiento. Mido las latencias L7 durante los picos y presto atención a los picos de pps, que se producen principalmente con TLS y HTTP/2. Si las colas de hardware no son suficientes, añado RPS para una distribución adicional a nivel de software. Este ajuste mantiene los tiempos de respuesta constante, aunque la utilización global de la capacidad parezca moderada. Controles periódicos de /proc/interrupciones muéstrame si los núcleos individuales se inclinan.
Proxy inverso de alta carga o pasarela API
Para los frontends con un elevado número de conexiones, fijo las colas de RX con precisión en núcleos definidos y coloco trabajadores proxy en núcleos cercanos. Decido conscientemente si irqbalance permanece activo o si el pinning fijo ofrece resultados más claros. Si no hay suficientes colas, selecciono específicamente RPS/XPS y calibro Coalescente, para evitar tormentas de IRQ. Esto me permite conseguir una baja latencia con una tasa de pps muy alta y mantener las latencias de cola bajo control. La documentación de cada cambio facilita las auditorías posteriores y mantiene el comportamiento previsible.
Elección del proveedor y criterios de hardware
Presto atención a los NIC con Cola múltiple, latencia fiable en la red troncal y versiones actualizadas del kernel de la plataforma. Una topología de CPU equilibrada y una clara separación NUMA impiden que las interrupciones de red lleguen a zonas de memoria remotas. Para proyectos con altas tasas de pps, la elección de la infraestructura hace honor a cada hora de puesta a punto porque el hardware proporciona reservas. En comparaciones prácticas, he trabajado bien con proveedores que revelan perfiles de rendimiento y proporcionan valores predeterminados compatibles con IRQ, como proveedores como webhoster.de. Estas configuraciones me permiten utilizar el equilibrio de IRQ, RSS y afinidad de forma eficaz y minimizar los tiempos de respuesta. estrecho para sostener.
Procedimiento paso a paso para su propia puesta a punto
Paso 1: Determino el estado actual con iperf3, sar, mpstat, nstat y ethtool -S, para tener claros los valores iniciales. Segundo paso: Si irqbalance no está en marcha, activo el servicio, espero bajo carga y comparo latencia, pps y caídas. Tercer paso: Ajusto el número de cola y la configuración RSS a los núcleos del nodo NUMA asociado. Paso 4: Pongo el regulador de CPU en „rendimiento“ y asigno los servicios centrales a los núcleos apropiados. Paso 5: Sólo entonces modifico la afinidad manual y el anclaje NUMA si los valores medidos siguen mostrando cuellos de botella. Paso 6: Compruebo las tendencias a lo largo de los días para clasificar de forma fiable los picos de eventos, copias de seguridad o picos de marketing.
Brevemente resumido
Eficaz Equilibrio de IRQ distribuye el trabajo de red entre los núcleos adecuados, reduce las latencias y evita caídas a altas tasas de pps. En combinación con NIC multicola, RSS/RPS, un controlador de CPU adecuado y una afinidad de hilos limpia, utilizo la pila de red de forma fiable. Valores medidos de ethtool -S, nstat, sar y iperf3 me guían paso a paso hacia mi objetivo en lugar de hurgar en la oscuridad. Si piensas en la topología NUMA, la asignación de IRQ y la ubicación de las aplicaciones de forma conjunta, puedes mantener los tiempos de respuesta al mínimo. bajo - incluso durante los picos de carga. Esto significa que el alojamiento de alta carga sigue siendo notablemente sensible sin quemar reservas innecesarias de CPU.
