42 votos

Mejora del rendimiento de TCP en una red gigabit con muchas conexiones y alto tráfico de paquetes pequeños

Estoy tratando de mejorar mi rendimiento TCP en una "red gigabit con muchas conexiones y alto tráfico de paquetes pequeños". Mi sistema operativo del servidor es Ubuntu 11.10 Server 64bit.

Hay alrededor de 50.000 (y creciendo) clientes conectados a mi servidor a través de TCP Sockets (todos en el mismo puerto).

El 95% de mis paquetes tienen un tamaño de 1-150 bytes (cabecera TCP y carga útil). El 5% restante varía entre 150 y 4096+ bytes.

Con la configuración de abajo mi servidor puede manejar tráfico de hasta 30 Mbps (full duplex).

¿Pueden aconsejarme las mejores prácticas para adaptar el sistema operativo a mis necesidades?

Mi /etc/sysctl.cong se ve así:

kernel.pid_max = 1000000
net.ipv4.ip_local_port_range = 2500 65000
fs.file-max = 1000000
#
net.core.netdev_max_backlog=3000
net.ipv4.tcp_sack=0
#
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.somaxconn = 2048
#
net.ipv4.tcp_rmem = 4096 87380 16777216 
net.ipv4.tcp_wmem = 4096 65536 16777216
#
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_mem = 50576   64768   98152
#
net.core.wmem_default = 65536
net.core.rmem_default = 65536
net.ipv4.tcp_window_scaling=1
#
net.ipv4.tcp_mem= 98304 131072 196608
#
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_rfc1337 = 1
net.ipv4.ip_forward = 0
net.ipv4.tcp_congestion_control=cubic
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 0
#
net.ipv4.tcp_orphan_retries = 1
net.ipv4.tcp_fin_timeout = 25
net.ipv4.tcp_max_orphans = 8192

Aquí están mis límites:

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 193045
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1000000
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1000000

[AÑADIDO]

Mis NICs son los siguientes:

$ dmesg | grep Broad
[    2.473081] Broadcom NetXtreme II 5771x 10Gigabit Ethernet Driver bnx2x 1.62.12-0 (2011/03/20)
[    2.477808] bnx2x 0000:02:00.0: eth0: Broadcom NetXtreme II BCM57711E XGb (A0) PCI-E x4 5GHz (Gen2) found at mem fb000000, IRQ 28, node addr d8:d3:85:bd:23:08
[    2.482556] bnx2x 0000:02:00.1: eth1: Broadcom NetXtreme II BCM57711E XGb (A0) PCI-E x4 5GHz (Gen2) found at mem fa000000, IRQ 40, node addr d8:d3:85:bd:23:0c

[AÑADIDO 2]

ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: on
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: off

[AÑADIDO 3]

 sudo ethtool -S eth0|grep -vw 0
 NIC statistics:
      [1]: rx_bytes: 17521104292
      [1]: rx_ucast_packets: 118326392
      [1]: tx_bytes: 35351475694
      [1]: tx_ucast_packets: 191723897
      [2]: rx_bytes: 16569945203
      [2]: rx_ucast_packets: 114055437
      [2]: tx_bytes: 36748975961
      [2]: tx_ucast_packets: 194800859
      [3]: rx_bytes: 16222309010
      [3]: rx_ucast_packets: 109397802
      [3]: tx_bytes: 36034786682
      [3]: tx_ucast_packets: 198238209
      [4]: rx_bytes: 14884911384
      [4]: rx_ucast_packets: 104081414
      [4]: rx_discards: 5828
      [4]: rx_csum_offload_errors: 1
      [4]: tx_bytes: 35663361789
      [4]: tx_ucast_packets: 194024824
      [5]: rx_bytes: 16465075461
      [5]: rx_ucast_packets: 110637200
      [5]: tx_bytes: 43720432434
      [5]: tx_ucast_packets: 202041894
      [6]: rx_bytes: 16788706505
      [6]: rx_ucast_packets: 113123182
      [6]: tx_bytes: 38443961940
      [6]: tx_ucast_packets: 202415075
      [7]: rx_bytes: 16287423304
      [7]: rx_ucast_packets: 110369475
      [7]: rx_csum_offload_errors: 1
      [7]: tx_bytes: 35104168638
      [7]: tx_ucast_packets: 184905201
      [8]: rx_bytes: 12689721791
      [8]: rx_ucast_packets: 87616037
      [8]: rx_discards: 2638
      [8]: tx_bytes: 36133395431
      [8]: tx_ucast_packets: 196547264
      [9]: rx_bytes: 15007548011
      [9]: rx_ucast_packets: 98183525
      [9]: rx_csum_offload_errors: 1
      [9]: tx_bytes: 34871314517
      [9]: tx_ucast_packets: 188532637
      [9]: tx_mcast_packets: 12
      [10]: rx_bytes: 12112044826
      [10]: rx_ucast_packets: 84335465
      [10]: rx_discards: 2494
      [10]: tx_bytes: 36562151913
      [10]: tx_ucast_packets: 195658548
      [11]: rx_bytes: 12873153712
      [11]: rx_ucast_packets: 89305791
      [11]: rx_discards: 2990
      [11]: tx_bytes: 36348541675
      [11]: tx_ucast_packets: 194155226
      [12]: rx_bytes: 12768100958
      [12]: rx_ucast_packets: 89350917
      [12]: rx_discards: 2667
      [12]: tx_bytes: 35730240389
      [12]: tx_ucast_packets: 192254480
      [13]: rx_bytes: 14533227468
      [13]: rx_ucast_packets: 98139795
      [13]: tx_bytes: 35954232494
      [13]: tx_ucast_packets: 194573612
      [13]: tx_bcast_packets: 2
      [14]: rx_bytes: 13258647069
      [14]: rx_ucast_packets: 92856762
      [14]: rx_discards: 3509
      [14]: rx_csum_offload_errors: 1
      [14]: tx_bytes: 35663586641
      [14]: tx_ucast_packets: 189661305
      rx_bytes: 226125043936
      rx_ucast_packets: 1536428109
      rx_bcast_packets: 351
      rx_discards: 20126
      rx_filtered_packets: 8694
      rx_csum_offload_errors: 11
      tx_bytes: 548442367057
      tx_ucast_packets: 2915571846
      tx_mcast_packets: 12
      tx_bcast_packets: 2
      tx_64_byte_packets: 35417154
      tx_65_to_127_byte_packets: 2006984660
      tx_128_to_255_byte_packets: 373733514
      tx_256_to_511_byte_packets: 378121090
      tx_512_to_1023_byte_packets: 77643490
      tx_1024_to_1522_byte_packets: 43669214
      tx_pause_frames: 228

Algo de información sobre SACK: ¿Cuándo hay que desactivar TCP SACK?

1 votos

0 votos

¿Cuál es el factor limitante? ¿Su CPU está al límite? Si es así, estás ladrando al árbol equivocado. Tienes que fijarte en lo que hace la CPU.

0 votos

¿Qué NIC tienes?

23voto

Nils Puntos 5486

El problema podría ser que está recibiendo demasiadas interrupciones en su tarjeta de red. Si el ancho de banda no es el problema, el problema es la frecuencia:

  • Aumentar los buffers de envío/recepción en la tarjeta de red

    ethtool -g eth0

Le mostrará la configuración actual (256 o 512 entradas). Probablemente puedas aumentarlas a 1024, 2048 o 3172. Más probablemente no tiene sentido. Esto es sólo un buffer de anillo que sólo se llena si el servidor no es capaz de procesar los paquetes entrantes lo suficientemente rápido.

Si el buffer comienza a llenarse, el control de flujo es un medio adicional para decirle al router o al switch que reduzca la velocidad:

  • Active el control de flujo de entrada/salida en el servidor y en los puertos del switch/router al que está conectado.

    ethtool -a eth0

Probablemente aparecerá:

Pause parameters for eth0:
Autonegotiate:  on
RX:             on
TX:             on

Comprueba en /var/log/messages la configuración actual de eth0. Busca algo como

eth0: El enlace está activo a 1000 Mbps, full duplex, control de flujo tx y rx

Si no ves tx y rx tus administradores de red tienen que ajustar los valores en el switch/router. En Cisco que es recibir / transmitir el control de flujo en.

Cuidado: El cambio de estos valores hará que su enlace baje y suba durante un tiempo muy corto (menos de 1s).

  • Si todo esto no ayuda, también puedes bajar la velocidad de la tarjeta de red a 100 MBit (haz lo mismo en los puertos del switch/router)

    ethtool -s eth0 autoneg off && ethtool -s eth0 speed 100

Pero en su caso yo diría - aumentar los búferes de recepción en el anillo NIC buffer.

0 votos

Mirando sus números de ethtool Yo diría que hay que poner los buffers de recepción de la tarjeta de red al máximo para evitar los descartes de RX. Espero que tu Broadcom tenga suficientes.

1 votos

Aumentar el buffering con TCP casi nunca es una buena idea. Ya tenemos demasiado búfer: bufferbloat.net/projects/bloat/wiki/Introducción

4 votos

Este buffer es un buffer de hardware directamente en la NIC. Actualizaré mi respuesta con más detalles. Como estás perdiendo paquetes entrantes necesitas ese buffer. Tengo un servidor similar en el que tuve que cambiar a una NIC diferente (de Broadcom a PCIe Intel) para poder aumentar estos buffers. Después de eso nunca más encontré paquetes RX perdidos.

6voto

kaji Puntos 1579

Puede que la siguiente no sea la respuesta definitiva, pero sin duda le dará algunas ideas

Intenta añadir esto a sysctl.conf

##  tcp selective acknowledgements. 
net.ipv4.tcp_sack = 1
##enable window scaling
net.ipv4.tcp_window_scaling = 1
##
net.ipv4.tcp_no_metrics_save = 1

Mientras que el tcp ack selectivo es bueno para un rendimiento óptimo en el caso de una red de gran ancho de banda . Pero cuidado con otros inconvenientes sin embargo. Se describen los beneficios del escalado de ventanas aquí . En cuanto a la tercera opción sysctl: Por defecto, TCP guarda varias métricas de conexión en la caché de rutas cuando la conexión se cierra, de modo que las conexiones establecidas en un futuro próximo pueden utilizarlas para establecer las condiciones iniciales. Normalmente, esto aumenta el rendimiento general, pero a veces puede causar una degradación del rendimiento. Si se establece, TCP no guardará las métricas en la caché al cerrar las conexiones.

Consulte con

ethtool -k ethX

para ver si la descarga está activada o no. Descarga de la suma de comprobación TCP y la descarga de grandes segmentos son compatibles con la mayoría de las NIC Ethernet actuales y, aparentemente Broadcom también lo apoya.

Pruebe a utilizar la herramienta

powertop

mientras la red está inactiva y cuando se alcanza la saturación de la red. Esto mostrará definitivamente si las interrupciones de la NIC son las culpables. El sondeo de dispositivos es una respuesta a esta situación. FreeBsd soporta la opción de sondeo dentro de ifconfig pero linux no tiene esa opción. Consulte este para habilitar el sondeo. Dice que BroadCom también soporta el polling, lo cual es una buena noticia para usted.

Puesta a punto del paquete jumbo puede que no te sirva, ya que has mencionado que tu tráfico consiste principalmente en paquetes pequeños. Pero de todos modos, pruébalo.

0 votos

2kaji, mañana probaré tus sugerencias. En cuanto a PowerTop, ¿debo ajustar el ahorro de energía si mi objetivo es el rendimiento?

0 votos

Sí, por supuesto, eso también podría ayudar. Mencioné powertop sólo para asegurarme si las interrupciones son el mal. La frecuencia de las interrupciones también podría ser cosechada de otras herramientas

0 votos

Veo altas "Interrupciones de reprogramación" - ¿podría ser una razón? ¿Qué son las "Interrupciones de reprogramación"?

3voto

Uri Ashi Puntos 6

He visto en la lista de ajustes que las marcas de tiempo están desactivadas, por favor no lo hagas. Eso es un viejo retroceso a los días de antaño cuando el ancho de banda era realmente caro y la gente quería ahorrar unos pocos bytes/paquete. Es usado, por ejemplo, por la pila TCP en estos días para decir si un paquete que llega a un socket en "CLOSE_WAIT" es un paquete viejo para la conexión o si es un nuevo paquete para una nueva conexión y ayuda en los cálculos de RTT. Y ahorrar los pocos bytes de una marca de tiempo no es NADA comparado con lo que van a añadir las direcciones IPv6. Desactivar las marcas de tiempo hace más daño que bien.

Esta recomendación de desactivar las marcas de tiempo es sólo un retroceso que sigue pasando de una generación de administradores de sistemas a la siguiente. Es una especie de "leyenda urbana".

2voto

user175978 Puntos 1

Es necesario distribuir la carga entre todos los núcleos de la CPU. Inicie 'irqbalance'.

2 votos

Esto no ayudará si una sola IRQ tiene una frecuencia muy alta. IRQBalance intenta distribuir las IRQs individuales a los procesadores lógicos adecuados - pero nunca habrá más de un procesador sirviendo a una sola IRQ.

2voto

avz2012 Puntos 49

En mi caso sólo un único tuninng:

net.ipv4.tcp_timestamps = 0

hizo un cambio muy grande y útil, el tiempo de carga del sitio se redujo en un 50%.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X