Linux incluye valores predeterminados de red calibrados para servidores de propósito general, no para instancias en la nube que manejan tráfico gigabit sostenido con cargas de trabajo sensibles a la latencia. Esos valores tenían sentido cuando la RAM era escasa y 100 Mbps era rápido. En un VPS moderno que gestiona pipelines de datos en tiempo real, tráfico de API de alta frecuencia o replicación de bases de datos entre continentes, limitan silenciosamente tu throughput e inflan la latencia de cola. La buena noticia es que tres capas de ajuste, el dimensionamiento de búferes TCP, la afinidad de interrupciones y la disciplina de cola, concentran la mayor parte de la ganancia, y todas son accesibles sin parches de kernel ni drivers exóticos.

Tamaños de búfer TCP: deja de desperdiciar ancho de banda

El concepto central es el Producto Ancho de Banda por Retardo (BDP, por sus siglas en inglés). El BDP es simplemente el ancho de banda multiplicado por el tiempo de ida y vuelta, e indica cuántos datos pueden estar en tránsito antes de que se acuse recibo del primer byte. A 10 Gbps con un RTT de 1 ms, eso equivale a 1,25 MB. En una ruta transcontinental con 100 ms de RTT necesitas 125 MB de búfer para mantener el enlace a plena capacidad. Ahora mira con qué valores viene el kernel de fábrica.

Los valores predeterminados típicos de Ubuntu y Debian son net.ipv4.tcp_rmem = 4096 131072 6291456 y net.core.rmem_max = 212992. El techo máximo del búfer de recepción, de aproximadamente 208 KB, impide que el kernel amplíe los búferes más allá de ese límite sin importar lo que la conexión necesite. En una ruta con RTT alto, ese techo por sí solo puede reducir el throughput efectivo en un orden de magnitud.

Elevar ese techo es el primer paso. Un punto de partida ampliamente adoptado para entornos de 10 Gbps establece net.core.rmem_max y net.core.wmem_max en 134217728 (128 MB), y net.ipv4.tcp_rmem en 4096 1048576 134217728. Los tres valores de tcp_rmem corresponden al mínimo, al predeterminado y al máximo. Ten cuidado con el valor predeterminado (el del medio): la documentación de RHEL 10 de Red Hat advierte explícitamente que configurarlo demasiado alto puede provocar colapso de búferes y picos de latencia, y recomienda no superar 524288 bytes (512 KiB) para ese valor. Deja que el ajuste automático, controlado por net.ipv4.tcp_moderate_rcvbuf, se encargue de ampliar los búferes hasta el máximo solo cuando una conexión realmente lo justifique.

El máximo adecuado para tu carga de trabajo es dos o tres veces el BDP calculado. Mide primero el RTT real con ping o ss --info, y dimensiona en consecuencia en lugar de copiar un valor genérico de un artículo. Persiste cada cambio en /etc/sysctl.d/99-network-tuning.conf y aplícalo con sysctl --system.

Elevar el techo del búfer no tiene coste cuando el ajuste automático está activado: el kernel solo asigna lo que la conexión realmente necesita. El riesgo va en el otro sentido: dejar el techo demasiado bajo limita silenciosamente todos los flujos con RTT alto.

Afinidad de interrupciones: saca el tráfico de CPU0

De forma predeterminada, la mayoría de los sistemas Linux enrutan todas las interrupciones de red a un único núcleo, normalmente CPU0. Con volúmenes de tráfico bajos esto es invisible. Bajo carga de alto throughput sostenido, CPU0 se satura mientras el resto de la máquina permanece inactivo, y la latencia de interrupción se dispara.

La solución es la afinidad de IRQ en SMP. Cada cola de recepción en una NIC multi-cola tiene su propia IRQ, y cada IRQ tiene una máscara de bits smp_affinity almacenada en /proc/irq/IRQ_NUMBER/smp_affinity. Activar el bit N en esa máscara permite que la CPU N gestione la interrupción. Distribuir las IRQ de cola entre núcleos, una cola por núcleo físico es un buen punto de partida, puede tener un impacto notable en el throughput multihilo.

Antes de tocar esos archivos, detén irqbalance. Sobreescribirá los ajustes manuales mientras esté en ejecución, y sus heurísticas optimizan para la gestión de energía, no para el throughput de red. Una vez detenido, utiliza el script set_irq_affinity de tu paquete de driver o ancla las colas manualmente. Para una NIC de cuatro colas en una máquina de ocho núcleos, distribuir las colas entre los núcleos 0, 2, 4 y 6 deja los núcleos impares libres para los hilos de aplicación que comparten el mismo nodo NUMA.

RPS y RFS para NICs de cola única en VPS

Muchas instancias VPS exponen una NIC virtual de cola única. La distribución de IRQ por hardware no está disponible, pero los equivalentes por software del kernel, Receive Packet Steering y Receive Flow Steering, cubren la mayor parte del mismo terreno.

RPS distribuye los paquetes entrantes entre las CPUs en función de un hash del flujo, evitando que un único núcleo gestione todo el procesamiento de recepción. No aumenta la tasa de interrupciones de hardware, aunque sí introduce interrupciones entre procesadores. Se configura por cola en /sys/class/net/DEVICE/queues/rx-0/rps_cpus escribiendo una máscara de bits de CPU. RFS va un paso más allá: dirige los paquetes al núcleo de CPU donde se está ejecutando el hilo de la aplicación consumidora, mejorando la tasa de aciertos en la caché de datos. Juntos, otorgan a las VMs de cola única una parte significativa de los beneficios de las colas múltiples sin ningún coste de hardware.

Disciplina de cola: lo que ocurre antes de que el paquete salga

La capa qdisc se sitúa entre la pila IP del kernel y el anillo de transmisión de la NIC. Cada paquete pasa por ella antes de la transmisión, y el algoritmo que elijas determina cómo gestiona el kernel las ráfagas, las pérdidas y la planificación bajo congestión.

El valor predeterminado en la mayoría de distribuciones es pfifo_fast, una FIFO de prioridad simple de tres bandas. Es suficiente para cargas de trabajo ligeras. Para tráfico sensible a la latencia que comparte un enlace con transferencias masivas, no lo es.

Dos alternativas merecen conocerse en profundidad:

  • fq_codel combina Fair Queuing con CoDel (Controlled Delay) AQM. CoDel es un algoritmo adaptativo sin parámetros que aborda los modos de fallo de esquemas AQM anteriores como RED. Mide el tiempo de permanencia del paquete en la cola en lugar de la longitud de esta, y descarta paquetes solo cuando llevan demasiado tiempo esperando. Fair Queuing aísla los flujos para que una única transferencia masiva no desplace al tráfico interactivo. Este es el valor predeterminado correcto para la mayoría de las cargas de trabajo mixtas.
  • fq (Fair Queue) sin CoDel es preferible cuando tienes una ruta de alto ancho de banda y RTT bajo y quieres cadencia por flujo. Permite que el kernel module los flujos TCP a su tasa estimada, suavizando las ráfagas que de otro modo provocarían retransmisiones.

Cambia el qdisc predeterminado con:

tc qdisc replace dev eth0 root fq_codel

Para que sea persistente tras los reinicios, establece net.core.default_qdisc = fq_codel en tu archivo sysctl. Verifica cuál está activo en este momento con tc qdisc show dev eth0.

Poniéndolo todo junto: una secuencia práctica

Ajustar en aislamiento genera ruido. La secuencia que produce señal limpia es: mide primero con iperf3 o netperf, aplica una capa de cambios, mide de nuevo y pasa a la siguiente capa. El dimensionamiento de búferes TCP tiene el mayor impacto en transferencias masivas con RTT alto. La afinidad de IRQ importa más en cargas de trabajo con alta tasa de paquetes y muchos flujos pequeños. La disciplina de cola moldea la experiencia del tráfico mixto donde latencia y throughput conviven en el mismo enlace.

En AMS1, donde el tráfico abarca regularmente el Benelux, el Reino Unido y los mercados de Europa occidental a través de AMS-IX, la varianza de RTT entre endpoints hace que el dimensionamiento de búferes basado en BDP no sea opcional: es la diferencia entre una conexión que satura el enlace y una que se detiene esperando acuses de recibo. La misma lógica aplica a cualquier VPS donde tus usuarios o servicios intermedios no estén en la misma ciudad que la instancia.

Ninguno de estos ajustes requiere acceso root en bare metal, un kernel personalizado ni tickets de soporte al proveedor. Todos están disponibles en la pila de red estándar de Linux en cualquier VPS. Los valores predeterminados son conservadores por una razón; ajustarlos es la forma de aprovechar el margen que siempre estuvo ahí.