39 votos

Mejorar el rendimiento de TCP a través de una red gigabit con un montón de conexiones y de alto tráfico de paquetes pequeños

Yo estoy tratando de mejorar mi rendimiento de TCP a través de una "red gigabit con un montón de conexiones y de alto tráfico de paquetes pequeños". Mi servidor de sistema operativo es Ubuntu Server 11.10 de 64 bits.

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

El 95% de mis paquetes tienen el tamaño de 1-150 bytes (TCP cabecera y la carga útil). El resto 5% variar desde 150 hasta 4096+ bytes.

Con la config por debajo de mi servidor puede manejar el tráfico de hasta 30 Mbps (full duplex).

Puede usted por favor, consejos de mejores prácticas para sintonizar OS para mis necesidades?

Mi /etc/sysctl.cong tiene este aspecto:

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

[AGREGADO]

Mi Nic son las 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

Un poco de información acerca de SACO: Cuando a su vez TCP SACK?

21voto

Nils Puntos 5486

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

  • Suba enviar/recibir búferes en la tarjeta de red

ethtool-g eth0

Se mostrará la configuración actual (256 o 512 entradas). Usted puede probablemente plantear estas a 1024, 2048 o 3172. Más probablemente no tenga sentido. Esto es sólo un búfer de anillo que solo se llena si el servidor no es capaz de procesar los paquetes entrantes con la suficiente rapidez.

Si el buffer empieza a llenar, el control de flujo es un medio adicional para decirle al router o switch a disminuir:

  • Activar el control de flujo en/saliente en el servidor y el switch/router los puertos que se encuentra conectada.

ethtool-eth0

Se propably mostrar:

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

Compruebe el archivo /var/log/messages para la configuración actual de eth0. Comprobar algo como:

eth0: el Enlace es de hasta 1000 Mbps, full duplex, control de flujo de tx y rx

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

Cuidado: el Cambio de estos Valores va a traer a su enlace de abajo y arriba por un tiempo muy corto (menos de 1s).

  • Si todo esto no ayuda - usted también puede reducir la velocidad de la tarjeta de red de 100 MBit (hacer lo mismo en el switch/router-puertos)

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

Pero en tu caso yo diría - elevar los búferes de recepción en la NIC búfer de anillo.

6voto

kaji Puntos 1579

Siguiente podría no ser la respuesta definitiva, pero definitivamente va a poner adelante algunas ideas

Trate de añadir estos 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 selectivo tcp ack es bueno para un rendimiento óptimo en el caso de alto ancho de banda de la red . Pero ten cuidado de otros inconvenientes , sin embargo. Beneficios de la escala de la ventana se describe aquí. Como para terceros sysctl opción: De forma predeterminada, TCP guarda varias conexión de métricas en la ruta de caché cuando se cierra la conexión, de modo que las conexiones establecidas en el futuro cercano puede utilizar estas para establecer las condiciones iniciales. Generalmente, esto aumenta el rendimiento general, pero a veces puede causar una degradación del rendimiento. Si se establece, TCP no caché métricas en el cierre de las conexiones.

Consulte con

ethtool -k ethX

a ver si la descarga está habilitado o no. Suma de comprobación de TCP descarga y descarga de segmentos grandes son apoyadas por la mayoría de la actual Nic de Ethernet y al parecer Broadcom también lo admite.

Trate de usar la herramienta

powertop

mientras que la red está inactiva y cuando la saturación de la red es alcanzado. Esto definitivamente va a mostrar si el NIC interrupciones son el culpable. Dispositivo de votación es una respuesta a esta situación. FreeBsd soporta sondeo interruptor de la derecha dentro de ifconfig, pero linux no tiene esa opción. Consulte esta para habilitar el sondeo. Es decir BroadCom también admite la agrupación que es una buena noticia para usted.

Paquete Jumbo tweak no podría corta para usted ya que usted menciona su tráfico constituye principalmente de pequeños paquetes. Pero bueno probarlo de todos modos !

2voto

user175978 Puntos 1

usted necesita para distribuir la carga entre todos los núcleos de la CPU. Inicio "irqbalance'.

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: