{"id":21057,"date":"2026-08-27T11:49:04","date_gmt":"2026-08-27T09:49:04","guid":{"rendered":"https:\/\/webhosting.de\/receive-side-scaling-rss-10g-25g-linux-server-optimierung-bitrate\/"},"modified":"2026-08-27T11:49:04","modified_gmt":"2026-08-27T09:49:04","slug":"escalado-del-lado-receptor-rss-10-g-25-g-optimizacion-de-servidores-linux-velocidad-de-transmision","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/receive-side-scaling-rss-10g-25g-linux-server-optimierung-bitrate\/","title":{"rendered":"Receive Side Scaling a 10 y 25 Gbit\/s: optimizaci\u00f3n del rendimiento para redes de servidores Linux modernas"},"content":{"rendered":"<p><strong>Escalado del lado receptor<\/strong> distribuye el tr\u00e1fico de red de forma selectiva a trav\u00e9s de varios n\u00facleos en enlaces de 10 y 25 Gbit\/s, para que los servidores Linux puedan gestionar altos caudales con baja latencia. Mostrar\u00e9 de forma pr\u00e1ctica c\u00f3mo activo el RSS, el <strong>Cues<\/strong> en el mapa de n\u00facleos y as\u00ed evitar cuellos de botella en las interrupciones y las aciertos de cach\u00e9.<\/p>\n\n<h2>Puntos centrales<\/h2>\n\n<p>Voy a resumir brevemente los aspectos m\u00e1s importantes para que puedas planificar r\u00e1pidamente los pr\u00f3ximos pasos.<\/p>\n<ul>\n  <li><strong>Distribuci\u00f3n de la carga<\/strong>: Los paquetes se distribuyen entre varios n\u00facleos a trav\u00e9s de varias colas.<\/li>\n  <li><strong>Localidad de la cach\u00e9<\/strong>: Un flujo permanece siempre en la misma cola.<\/li>\n  <li><strong>Funci\u00f3n hash<\/strong>: El hash de cu\u00e1druples distribuye los flujos de manera uniforme entre las colas.<\/li>\n  <li><strong>afinidad<\/strong>: Una asignaci\u00f3n espec\u00edfica de IRQ reduce las latencias.<\/li>\n  <li><strong>Escala<\/strong>: A partir de 10\/25 Gbit\/s, RSS garantiza un alto rendimiento.<\/li>\n<\/ul>\n<p>Estos puntos est\u00e1n interrelacionados y sustentan la <strong>Actuaci\u00f3n<\/strong> sobre cargas de trabajo reales. Mi prioridad es, en primer lugar, el n\u00famero correcto de colas y, a continuaci\u00f3n, la <strong>CPU<\/strong>-Afinidad. A continuaci\u00f3n, compruebo los par\u00e1metros de hash y los ajustes de precisi\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\/08\/servernetzwerk-performance-2947.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Qu\u00e9 ofrece el \u00abReceive Side Scaling\u00bb<\/h2>\n\n<p>RSS divide la recepci\u00f3n de paquetes en varios <strong>Colas de recepci\u00f3n<\/strong>, que asigno a n\u00facleos espec\u00edficos de la CPU para que ning\u00fan n\u00facleo concreto se convierta en un cuello de botella. Esto reduce los picos de interrupciones duras y suaviza el procesamiento mediante SoftIRQs, lo que reduce los picos de latencia y aumenta el rendimiento. Cada cola activa sus propias interrupciones, que asigno de forma fija a determinados n\u00facleos para mantener la coherencia de las rutas de datos. Esta coherencia favorece la <strong>Cache<\/strong>-Localidad, porque un flujo siempre incide en el mismo n\u00facleo. Es precisamente esta interacci\u00f3n la que, con altas tasas de PPS, se traduce directamente en una eficiencia cuantificable.<\/p>\n\n<h2>As\u00ed funciona el RSS desde el punto de vista t\u00e9cnico<\/h2>\n\n<p>La NIC crea, a partir de la IP de origen\/destino y el puerto de origen\/destino, un <strong>Hash<\/strong> y lo utiliza como \u00edndice para la tabla de indirecci\u00f3n, que apunta a las colas. De este modo, los paquetes de un flujo siempre terminan en la misma cola y, por lo tanto, permanecen vinculados al mismo n\u00facleo. Los distintos flujos se distribuyen de manera uniforme, siempre que las claves de hash y los campos de protocolo est\u00e9n configurados adecuadamente. De este modo, la carga de trabajo se distribuye cerca de la <strong>Hardware<\/strong>, lo que hace que el n\u00facleo tenga que realizar menos operaciones de equilibrio y se reduzca la sobrecarga. Eso es precisamente lo que quiero para mantener bajo el procesamiento de paquetes por n\u00facleo a 10G\/25G.<\/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\/08\/linuxnetzwerke_tuning4683.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Por qu\u00e9 el RSS es importante a partir de 10 y 25 Gbit\/s<\/h2>\n\n<p>A 1 Gbit\/s, a menudo basta con un solo <strong>N\u00facleo<\/strong> la carga de paquetes, pero a partir de 10 Gbit\/s el equilibrio se rompe r\u00e1pidamente. Los paquetes peque\u00f1os hacen que aumente la cifra de PPS, lo que provoca que un n\u00facleo alcance r\u00e1pidamente el 100 % de carga y se produzcan ca\u00eddas. Es precisamente entonces cuando el RSS act\u00faa como un multiplicador del ancho de banda \u00fatil. Distribuyo la carga entre varios <strong>N\u00facleos<\/strong>, reduce los cambios de contexto y mantiene las curvas de latencia m\u00e1s estables. El resultado: el rendimiento real solo se aproxima a la velocidad de enlace cuando el RSS funciona correctamente.<\/p>\n\n<h2>Configurar RSS en el servidor Linux<\/h2>\n\n<p>En Linux, gestiono el RSS principalmente a trav\u00e9s de <strong>ethtool<\/strong>, opciones del controlador y sysfs, para que las capacidades de la tarjeta de red se apliquen realmente. Primero leo el n\u00famero m\u00e1ximo de canales de recepci\u00f3n (RX) y, a continuaci\u00f3n, establezco un n\u00famero de colas adecuado para la CPU. A continuaci\u00f3n, compruebo el hash RSS para TCP\/UDP y, opcionalmente, para VLAN o t\u00faneles, con el fin de que los perfiles de carga se distribuyan correctamente. Para el ruido de fondo de la distribuci\u00f3n de interrupciones, me ayuda <a href=\"https:\/\/webhosting.de\/es\/configurar-el-equilibrio-de-irq-en-linux-para-un-servidor\/\">Equilibrio de IRQ<\/a>, aunque prefiero marcar manualmente las colas cr\u00edticas. As\u00ed es como las vinculo <strong>Cues<\/strong> se adapte perfectamente a la topolog\u00eda del host y evite desplazamientos indeseados.<\/p>\n\n<h2>Tabla de indirecci\u00f3n, clave RSS y ajuste fino del hash: comandos concretos<\/h2>\n\n<p>En primer lugar, compruebo la distribuci\u00f3n actual y la clave de la tarjeta de red:<\/p>\n<pre><code>ethtool -x eth0 #: mostrar la tabla de indirecci\u00f3n (colas de recepci\u00f3n) y la clave RSS\nethtool -n eth0 rx-flow-hash tcp4\nethtool -n eth0 rx-flow-hash udp4\n<\/code><\/pre>\n<p>Para conseguir una distribuci\u00f3n limpia y uniforme, configuro la tabla de indirecci\u00f3n con el n\u00famero de colas deseado. Con 16 colas, elijo una asignaci\u00f3n uniforme:<\/p>\n<pre><code>ethtool -X eth0 equal 16  Distribuci\u00f3n # de forma uniforme en 16 colas\n<\/code><\/pre>\n<p>Si es necesario, adapto los campos de hash. Para TCP4 con cu\u00e1druples (s = IP de origen, d = IP de destino, f = puerto de origen, n = puerto de destino):<\/p>\n<pre><code>ethtool -N eth0 rx-flow-hash tcp4 sdfn\nethtool -N eth0 rx-flow-hash udp4 sdfn\nethtool -N eth0 rx-flow-hash tcp6 sdfn\nethtool -N eth0 rx-flow-hash udp6 sdfn\n<\/code><\/pre>\n<p>Algunos controladores tambi\u00e9n permiten establecer una clave RSS propia (por ejemplo, para una mejor distribuci\u00f3n en casos especiales):<\/p>\n<pre><code>ethtool -X eth0 hkey   # solo si el controlador o la tarjeta de red lo admiten\n<\/code><\/pre>\n\n<h2>Configurar correctamente la afinidad de la CPU y NUMA<\/h2>\n\n<p>Asigno cada cola de recepci\u00f3n mediante <strong>Afinidad IRQ<\/strong> asigna las colas a n\u00facleos espec\u00edficos y ten en cuenta la arquitectura NUMA, para que los datos recorran una distancia m\u00ednima a trav\u00e9s del controlador de memoria. Si la tarjeta de red (NIC) se ejecuta en el nodo 0, tambi\u00e9n asigno las colas principales a n\u00facleos del nodo 0 y coloco las cargas de trabajo cerca de ellos. Esta proximidad reduce los accesos remotos y disminuye considerablemente las latencias de memoria. Para ello, resulta \u00fatil disponer de un perfil para las colas productivas, as\u00ed como de n\u00facleos separados para las tareas de gesti\u00f3n y descarga. Quien desee profundizar m\u00e1s, encontrar\u00e1 indicaciones para el ajuste fino en <a href=\"https:\/\/webhosting.de\/es\/servidor-afinidad-irq-multinucleo-optimizacion-de-red-rendimiento\/\">Afinidad IRQ<\/a>, en lo que respecta a la planificaci\u00f3n por <strong>N\u00facleo<\/strong> simplificado.<\/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\/08\/linux-server-network-tuning-2478.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Gu\u00eda pr\u00e1ctica sobre la afinidad de IRQ: de las IRQ a una asignaci\u00f3n estable de n\u00facleos<\/h2>\n\n<p>Primero averiguo qu\u00e9 IRQ corresponden a las colas de recepci\u00f3n y, a continuaci\u00f3n, las asigno de forma fija:<\/p>\n<pre><code>grep -E \"eth0.*Rx\" \/proc\/interrupts\ncat \/sys\/class\/net\/eth0\/device\/numa_node\n<\/code><\/pre>\n<p>La asignaci\u00f3n la realizo mediante <code>smp_affinity_list<\/code>, para no tener que hacer c\u00e1lculos complicados. Ejemplo: colas RX 0\u20137 en los n\u00facleos 2\u20139:<\/p>\n<pre><code>Ejemplo #: asignar IRQ a los n\u00facleos 2-9 (una l\u00ednea por IRQ)\necho 2  &gt; \/proc\/irq\/\/smp_affinity_list\necho 3  &gt; \/proc\/irq\/\/smp_affinity_list\necho 4  &gt; \/proc\/irq\/\/smp_affinity_list\n...\necho 9  &gt; \/proc\/irq\/\/smp_affinity_list\n<\/code><\/pre>\n<p>Importante: MSI-X debe estar activado para que cada cola tenga sus propias interrupciones. Si utilizo la asignaci\u00f3n manual de pines, bloqueo <code>irqbalance<\/code> para estas IRQ (por ejemplo, mediante una lista negra) o desactivar el servicio de forma selectiva en los hosts con una estructura est\u00e1tica. Adem\u00e1s, compruebo NUMA con <code>lscpu<\/code> y la asignaci\u00f3n de PCIe, para no generar rutas entre nodos.<\/p>\n\n<h2>Configuraci\u00f3n de hash y protocolos<\/h2>\n\n<p>Defino los campos hash de tal manera que los aut\u00e9nticos <strong>Tr\u00e1fico<\/strong>-Distribuir bien los patrones, en lugar de que se concentren en unas pocas colas. Para TCP\/UDP utilizo el cu\u00e1druplet; para IPv6, algo similar, mientras que en VXLAN o GRE tengo en cuenta campos adicionales de la encapsulaci\u00f3n. Algunas tarjetas de red ofrecen claves de hash configurables, que adapto a la carga de trabajo dominante. En cuanto observo una concentraci\u00f3n de carga en colas concretas, reajusto la selecci\u00f3n de hash. Este paso requiere poco tiempo, pero evita una <strong>desequilibrio<\/strong> con un elevado n\u00famero de conexiones.<\/p>\n\n<h2>Coalescencia de interrupciones y PPS<\/h2>\n\n<p>Combino RSS con un uso moderado de <strong>Interrupci\u00f3n coalescente<\/strong>, para agrupar el tr\u00e1fico con gran volumen de PPS en lotes manejables. Esto reduce la sobrecarga de interrupciones, pero no debe aumentar la latencia de los servicios m\u00e1s sensibles. Por eso mido los tiempos de ida y vuelta y modifico los valores de coalescencia de forma gradual. Quien gestione cargas de almacenamiento o copias de seguridad puede agruparlas de forma m\u00e1s clara que en el caso de las API de capa 7 o el VoIP. En resumen, equilibro <strong>Latencia<\/strong> frente al rendimiento, hasta que ambos coincidan.<\/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\/08\/performance_tuning_linux_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>La coalescencia en la pr\u00e1ctica: perfiles y puntos de medici\u00f3n<\/h2>\n\n<p>Empiezo con unos valores predeterminados moderados y voy ajust\u00e1ndolos poco a poco hasta alcanzar el nivel \u00f3ptimo para cada carga de trabajo. Tres perfiles iniciales que han dado buenos resultados:<\/p>\n<ul>\n  <li>API\/Baja latencia: <code>rx-usecs 2\u20136<\/code>, <code>rx-frames 16\u201332<\/code>, adaptativo desactivado<\/li>\n  <li>Vers\u00e1til: <code>rx-usecs 8\u201316<\/code>, <code>rx-frames 32\u201364<\/code>, adaptativa a<\/li>\n  <li>A granel\/Almacenamiento: <code>24-48 rx-usecs<\/code>, <code>rx-frames 128\u2013256<\/code>, adaptativa a<\/li>\n<\/ul>\n<pre><code>ethtool -c eth0\nethtool -C eth0 rx-usecs 12 rx-frames 64 adaptive-rx on\n<\/code><\/pre>\n<p>Para ello, mido las latencias p95\/p99, el PPS, la carga de la CPU por n\u00facleo y las retransmisiones. En cuanto observo un aumento de la varianza en API\/VoIP, procedo a <code>rx-usecs<\/code> de nuevo hacia abajo. En el almacenamiento, prefiero escalar hacia arriba mediante fotogramas para ahorrar interrupciones.<\/p>\n\n<h2>RSS en entornos de 10 Gbit<\/h2>\n\n<p>En las tarjetas de red de 10G, suelo trabajar con valores de entre 8 y 16 <strong>Cues<\/strong> por puerto, siempre que la CPU disponga de suficientes n\u00facleos. De este modo, los servidores web, las pasarelas de almacenamiento y los hosts de virtualizaci\u00f3n se escalan correctamente a trav\u00e9s de numerosas conexiones paralelas. Asigno las colas principales a los n\u00facleos libres y, a continuaci\u00f3n, mido el PPS, la latencia y las retransmisiones. Si se producen p\u00e9rdidas de paquetes, compruebo la coalescencia, el hash y la utilizaci\u00f3n de cada cola. A continuaci\u00f3n, ajusto la <strong>afinidad<\/strong>, hasta que la carga de trabajo parezca uniforme.<\/p>\n\n<h2>RSS en configuraciones de 25 Gbit y Multi-25G<\/h2>\n\n<p>A 25 Gbit\/s, el PPS y la carga del bus aumentan, por lo que yo <strong>NUMA<\/strong>-Presto m\u00e1s atenci\u00f3n a la gesti\u00f3n de colas y a las descargas. La descarga de recepci\u00f3n de grandes paquetes (LRO) o RSC pueden reducir la carga de paquetes en la pila, siempre que las aplicaciones lo toleren. Adem\u00e1s, compruebo los carriles PCIe para descartar cuellos de botella ajenos a la red. En hosts con varios enlaces de 25G, separo las colas y la afinidad de forma estricta seg\u00fan las tareas y los nodos. As\u00ed es como utilizo <strong>Ancho de banda<\/strong> y n\u00facleos de forma eficiente, sin caer en el tr\u00e1fico entre nodos.<\/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\/08\/linuxnetztuning_7234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Detalles sobre el hardware y los controladores: lo que tengo en cuenta<\/h2>\n\n<p>No todas las tarjetas de red se comportan igual. Las generaciones de Intel (por ejemplo, ixgbe, i40e, ice) ofrecen funciones como Flow Director\/ATR, que vinculan los flujos de forma espec\u00edfica a colas, lo cual resulta \u00fatil si quiero suavizar los picos de tr\u00e1fico. Mellanox mlx5 puede admitir aRFS por hardware, lo que reduce la carga de la CPU cuando la pila atiende a muchos sockets. Decido caso por caso si activo estas funciones y mido si mejoran la distribuci\u00f3n. En los sistemas de enrutamiento\/NAT, suelo desactivar LRO y utilizo GRO para mantener la coherencia de las cabeceras; en cargas de trabajo exclusivamente de servidor, LRO\/GRO pueden ayudar a mitigar la presi\u00f3n de PPS. Tambi\u00e9n es importante disponer de suficientes vectores MSI-X por cola y de versiones de firmware correctas.<\/p>\n\n<h2>RSS en virtualizaci\u00f3n y contenedores<\/h2>\n\n<p>En el hipervisor combino los recursos f\u00edsicos <strong>RSS<\/strong>-Colas con vNIC compatibles con m\u00faltiples colas, como virtio-net, para que los sistemas invitados no sufran cuellos de botella artificiales. Presto atenci\u00f3n a la asignaci\u00f3n de CPU de las m\u00e1quinas virtuales y configuro la proximidad NUMA de sus vCPU a la NIC f\u00edsica. De este modo, los datos permanecen en el entorno local y el host paga menos por los accesos a la memoria. En el caso de los contenedores, asigno los pods cr\u00edticos a los n\u00facleos adecuados y mantengo las colas del host libres de carga molesta. Este orden aumenta el <strong>Eficacia<\/strong> en el caso de los microservicios, donde se generan muchos flujos peque\u00f1os.<\/p>\n\n<h2>C\u00f3mo utilizar correctamente SR-IOV y VF-RSS<\/h2>\n\n<p>Con SR-IOV asigno a las m\u00e1quinas virtuales (VM) sus propias funciones virtuales (VF), que a su vez pueden proporcionar varias colas y RSS. Preveo un n\u00famero suficiente de VF por puerto, tengo en cuenta la capacidad de MSI-X y asigno las IRQ de las VF en la m\u00e1quina virtual de acuerdo con sus vCPU. En los sistemas invitados de Linux, activo expl\u00edcitamente la funci\u00f3n Multi-Queue; de lo contrario, la vNIC suele permanecer en un solo nivel:<\/p>\n<pre><code># en el sistema invitado (ejemplo de virtio-net)\nethtool -l eth0\nethtool -L eth0 combined 4\n<\/code><\/pre>\n<p>Distribuyo los hosts con varias m\u00e1quinas virtuales (VM) estrictamente por nodo NUMA y por carga de trabajo, para que las m\u00e1quinas virtuales no se interfieran entre s\u00ed en las mismas rutas f\u00edsicas de recepci\u00f3n (RX).<\/p>\n\n<h2>Supervisi\u00f3n y resoluci\u00f3n de problemas<\/h2>\n\n<p>Superviso la ocupaci\u00f3n por <strong>Cola<\/strong>, n\u00facleos individuales, p\u00e9rdidas de paquetes y retransmisiones, para detectar desequilibrios en una fase temprana. Si un n\u00facleo se destaca y los dem\u00e1s permanecen inactivos, a menudo es porque la afinidad o el n\u00famero de colas no son los adecuados. En esos casos, compruebo uno tras otro los campos hash, las m\u00e1scaras de IRQ y los valores de coalescencia. Adem\u00e1s, compruebo el <a href=\"https:\/\/webhosting.de\/es\/softirq-cpu-hosting-red-rendimiento-optimizacion-datacenter\/\">Carga de SoftIRQ<\/a>, porque ofrece indicios de efectos de desplazamiento. Solo cuando estas se\u00f1ales parecen estables, aumente el tr\u00e1fico o ampl\u00ede <strong>Cues<\/strong> continuar.<\/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\/08\/servernetzwerk-optimierung-4721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>RPS, RFS y XPS: complementos de software para RSS<\/h2>\n\n<p>Si una tarjeta de red tiene pocas colas o si utilizo bonding o tunneling, complemento RSS con <strong>RPS<\/strong> (Receive Packet Steering) y <strong>RFS<\/strong> (Receive Flow Steering). RPS distribuye las SoftIRQ entre los n\u00facleos, mientras que RFS vincula los flujos al n\u00facleo en el que est\u00e1 activo el socket correspondiente. Yo activo ambos de forma selectiva:<\/p>\n<pre><code># Aumentar el n\u00famero global de entradas de flujo (RFS)\necho 32768 &gt; \/proc\/sys\/net\/core\/rps_sock_flow_entries\n\n# Configurar el n\u00famero de CPU por cola de recepci\u00f3n para RPS (m\u00e1scara de ejemplo, \u00a1adaptarla!)\nfor f in \/sys\/class\/net\/eth0\/queues\/rx-*\/rps_cpus; do echo ffff &gt; \"$f\"; done\n\nConfigurar la tabla de flujos por cola de recepci\u00f3n # para RFS\nfor f in \/sys\/class\/net\/eth0\/queues\/rx-*\/rps_flow_cnt; do echo 4096 &gt; \"$f\"; done\n<\/code><\/pre>\n<p>En el lado de TX utilizo <strong>XPS<\/strong> (Transmit Packet Steering), para que los paquetes salientes sean enviados desde el n\u00facleo que los ha generado:<\/p>\n<pre><code>for f in \/sys\/class\/net\/eth0\/queues\/tx-*\/xps_cpus; do echo ffff &gt; \"$f\"; done\n<\/code><\/pre>\n<p>RPS\/RFS\/XPS consumen algo de CPU, pero resultan \u00fatiles cuando me faltan colas a nivel de hardware o cuando quiero mantener estrictamente la localidad de los sockets.<\/p>\n\n<h2>Rendimiento de flujo \u00fanico, GRO\/TSO y sondeo de actividad<\/h2>\n\n<p>Un flujo individual permanece vinculado a un n\u00facleo por una buena raz\u00f3n. Si quiero aumentar el ancho de banda de un flujo individual, apuesto por las descargas (GRO\/TSO), una frecuencia de n\u00facleo elevada y una coalescencia adecuada. Para las rutas en las que la latencia es cr\u00edtica, se puede <strong>Sondeo ocupado<\/strong> ayudar:<\/p>\n<pre><code>Establecer un valor bajo para # y realizar la medici\u00f3n\nsysctl -w net.core.busy_read=25\nsysctl -w net.core.busy_poll=25\n<\/code><\/pre>\n<p>El \u00abbusy polling\u00bb reduce los cambios de contexto, pero consume tiempo de CPU. Solo lo activo cuando las latencias p99 son importantes, y siempre compruebo los efectos sobre la carga total y la latencia de cola. Por lo general, mantengo GRO en los servidores y utilizo LRO en funci\u00f3n de su funci\u00f3n; en los middleboxes, opto por un enfoque conservador para no interferir en el procesamiento de encabezados ni en la consistencia de los hash.<\/p>\n\n<h2>Recomendaciones y ejemplos: colas, afinidad, comandos<\/h2>\n\n<p>Como punto de partida, elijo un n\u00famero de colas que se adapte a la <strong>CPU<\/strong> Ajusta los valores, observa la carga por cola y ve ajust\u00e1ndolos poco a poco. Con 10G suelen bastar entre 8 y 16 colas; con 25G suelo establecer un n\u00famero mayor, siempre que haya n\u00facleos disponibles. Para la afinidad, utilizo m\u00e1scaras claras por cada IRQ, para poder analizar m\u00e1s f\u00e1cilmente las rutas posteriormente. La siguiente tabla ofrece valores orientativos resumidos, que luego verifico mediante mediciones. Solo los resultados de las mediciones determinan si <strong>m\u00e1s<\/strong> aumenta o reduce.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Velocidad de conexi\u00f3n<\/th>\n      <th>Colas RX t\u00edpicas<\/th>\n      <th>Ejemplos de comandos<\/th>\n      <th>Notas<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>10 Gbit\/s<\/td>\n      <td>8-16<\/td>\n      <td><code>ethtool -l eth0<\/code> | <code>ethtool -L eth0 rx 16<\/code><\/td>\n      <td><strong>Coalescente<\/strong> mantener un nivel moderado, comprobar la latencia L7<\/td>\n    <\/tr>\n    <tr>\n      <td>25 Gbit\/s<\/td>\n      <td>16\u201332+<\/td>\n      <td><code>grep . \/proc\/interrupts<\/code> | M\u00e1scaras de IRQ mediante <code>echo<\/code><\/td>\n      <td><strong>NUMA<\/strong> Tener en cuenta: comprobar los carriles PCIe<\/td>\n    <\/tr>\n    <tr>\n      <td>Multi-25G<\/td>\n      <td>Por puerto, por separado<\/td>\n      <td>Activar vNIC con colas m\u00faltiples (por ejemplo, virtio)<\/td>\n      <td>Colas por n\u00facleos y <strong>Cargas de trabajo<\/strong> dividir<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Estos valores orientativos son solo un punto de partida, no el objetivo, ya que las cargas de trabajo var\u00edan mucho. Registro los cambios, realizo mediciones antes y despu\u00e9s del ajuste y, por lo dem\u00e1s, mantengo el entorno sin modificaciones. En cuanto el sistema se mantiene estable bajo carga de producci\u00f3n, congelo la configuraci\u00f3n. M\u00e1s adelante, vuelvo a realizar mediciones tras las actualizaciones del n\u00facleo o de los controladores. De este modo, me mantengo en <strong>RSS<\/strong> Un proceso bien encaminado y resultados seguros y reproducibles.<\/p>\n\n<h2>Problemas habituales y soluciones<\/h2>\n\n<p>Demasiado pocos <strong>Cues<\/strong> Sobrecargar n\u00facleos concretos; un n\u00famero excesivo aumenta la carga administrativa y perjudica la tasa de aciertos de la cach\u00e9. Una afinidad inadecuada desv\u00eda las interrupciones hacia n\u00facleos ya sobrecargados o hacia nodos NUMA incorrectos. Asimismo, un hash inadecuado provoca que los flujos dominantes obstruyan las colas. Lo resuelvo paso a paso: ajustar el n\u00famero de colas, corregir la afinidad, ampliar los campos de hash y ajustar con precisi\u00f3n la coalescencia. Justifico cada cambio con <strong>M\u00e9tricas<\/strong>, antes de pasar a la siguiente palanca.<\/p>\n\n<h2>Escenarios pr\u00e1cticos<\/h2>\n\n<p>Un servidor de almacenamiento con 10G se beneficia r\u00e1pidamente de 8-12 <strong>Cues<\/strong> adem\u00e1s de una coalescencia moderada, para que las transferencias masivas se realicen sin problemas. Un servidor de API con un elevado n\u00famero de conexiones suele necesitar campos hash m\u00e1s precisos y una menor latencia en las interrupciones. Los hosts de virtualizaci\u00f3n se benefician notablemente cuando la funci\u00f3n \u00abvNIC-Multi-Queue\u00bb est\u00e1 activa en el lado del invitado y se adapta a la configuraci\u00f3n del host. Las cargas de trabajo de los contenedores funcionan mejor cuando los pods cr\u00edticos se ejecutan cerca de la NIC y de la memoria NUMA. Ampl\u00edo estos patrones seg\u00fan la situaci\u00f3n, mediante <strong>PPS<\/strong>, compara las retransmisiones y la distribuci\u00f3n de colas.<\/p>\n\n<h2>Las plataformas de alto rendimiento como ventaja<\/h2>\n\n<p>Configuraciones de alojamiento con <strong>RSS<\/strong>, las tarjetas de red con m\u00faltiples colas y una afinidad bien definida aportan reservas apreciables en momentos de m\u00e1xima carga. Quien eval\u00fae ofertas de servidores deber\u00eda preguntar espec\u00edficamente por la capacidad de m\u00faltiples colas, el \u00abNUMA-Pinning\u00bb y la supervisi\u00f3n. Un proveedor que aplique estos aspectos de forma visible suele obtener curvas de rendimiento notablemente mejores. Para soluciones de servidores y alojamiento de alto rendimiento, recomiendo sin duda alguna webhoster.de. Esta orientaci\u00f3n da sus frutos en <strong>Actuaci\u00f3n<\/strong> y estabilidad, sobre todo cuando hay muchos flujos paralelos.<\/p>\n\n<h2>Resumen para la pr\u00e1ctica<\/h2>\n\n<p>Activo <strong>Reciba<\/strong> Escalado lateral: establezco un n\u00famero razonable de colas, asigno las IRQ a los n\u00facleos adecuados y compruebo la configuraci\u00f3n del hash. A continuaci\u00f3n, optimizo la coalescencia para reducir la latencia, presto atenci\u00f3n a la proximidad NUMA y distribuyo las cargas de trabajo de forma coherente. En virtualizaci\u00f3n, utilizo colas m\u00faltiples hasta en los sistemas invitados y mantengo sincronizados el pinning y la afinidad. Las mediciones de PPS, carga de colas, retransmisiones y latencia determinan el siguiente paso. Quien proceda as\u00ed, sacar\u00e1 el m\u00e1ximo partido a 10G y 25G, y mantendr\u00e1 <strong>Latencia<\/strong> en este contexto y obtiene un rendimiento de red fiable.<\/p>","protected":false},"excerpt":{"rendered":"<p>El \u00abReceive Side Scaling\u00bb optimiza las redes de 10G y 25G distribuyendo los paquetes entre varios n\u00facleos de la CPU. Descubre c\u00f3mo configurar el RSS en un servidor Linux y sacar as\u00ed el m\u00e1ximo rendimiento a tu configuraci\u00f3n. Enfoque: el \u00abReceive Side Scaling\u00bb en entornos de alta velocidad.<\/p>","protected":false},"author":1,"featured_media":21050,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21057","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":"159","_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":"receive side scaling","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":"21050","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21057","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=21057"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21057\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/21050"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=21057"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=21057"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=21057"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}