42 votes

Améliorer les performances TCP sur un réseau gigabit avec de nombreuses connexions et un trafic élevé de petits paquets

Je cherche à améliorer mon débit TCP sur un "réseau gigabit avec beaucoup de connexions et un trafic élevé de petits paquets". Mon système d'exploitation serveur est Ubuntu 11.10 Server 64bit.

Environ 50 000 clients (et en augmentation) sont connectés à mon serveur via des sockets TCP (tous sur le même port).

95% de mes paquets ont une taille de 1 à 150 octets (en-tête et charge utile TCP). Les 5% restants varient de 150 à plus de 4096 octets.

Avec la configuration ci-dessous, mon serveur peut gérer un trafic allant jusqu'à 30 Mbps (full duplex).

Pouvez-vous me conseiller sur les meilleures pratiques pour régler le système d'exploitation en fonction de mes besoins ?

Mon fichier /etc/sysctl.cong ressemble à ceci :

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

Voici mes limites :

$ 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

[AJOUTÉ]

Mes cartes réseau sont les suivantes :

$ 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

[AJOUTÉ 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

[AJOUTÉ 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

Informations supplémentaires sur SACK : Quand désactiver TCP SACK ?

23voto

Nils Points 7622

Le problème pourrait être que vous recevez trop d'interruptions sur votre carte réseau. Si la bande passante n'est pas le problème, la fréquence est le problème :

  • Augmentez les tampons d'envoi/réception de la carte réseau

    ethtool -g eth0

Vous montrera les paramètres actuels (256 ou 512 entrées). Vous pouvez probablement les augmenter à 1024, 2048 ou 3172. Plus ne fait probablement pas de sens. Il s'agit simplement d'un tampon en anneau qui ne se remplit que si le serveur n'est pas capable de traiter assez rapidement les paquets entrants.

Si le tampon commence à se remplir, le contrôle de flux est un moyen supplémentaire de dire au routeur ou au commutateur de ralentir :

  • Activez le contrôle de flux en sortie et en entrée sur le serveur et sur les ports du commutateur/routeur auxquels il est connecté.

    ethtool -a eth0

Montrera probablement :

Paramètres de pause pour eth0:
Auto-négociation : activée
RX : activé
TX : activé

Vérifiez /var/log/messages pour les paramètres actuels de eth0. Recherchez quelque chose comme :

eth0: La liaison est établie à 1000 Mbps, full duplex, contrôle de flux tx et rx

Si vous ne voyez pas tx et rx, vos administrateurs réseau doivent ajuster les valeurs sur le commutateur/routeur. Sur Cisco, il s'agit de receive/transmit flow control on.

Attention : Changer ces valeurs fera descendre et remonter votre liaison pour un très court instant (moins d'1s).

  • Si tout cela n'aide pas - vous pouvez également diminuer la vitesse de la carte réseau à 100 MBit (faites de même sur les ports du commutateur/routeur)

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

Mais dans votre cas, je dirais - augmentez les tampons de réception dans le tampon en anneau de la carte NIC.

6voto

bosky101 Points 301

Les éléments suivants pourraient ne pas constituer la réponse définitive, mais ils mettront certainement en avant quelques idées

Essayez d'ajouter ceci à 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

Alors que l'ack tcp sélectif est bon pour des performances optimales dans le cas d'un réseau à large bande passante. Mais méfiez-vous des autres inconvénients. Les avantages de la mise à l'échelle de la fenêtre sont décrits ici. Quant à la troisième option sysctl : Par défaut, TCP sauve diverses métriques de connexion dans le cache de routage lorsque la connexion se termine, de sorte que les connexions établies dans un avenir proche peuvent les utiliser pour définir les conditions initiales. Généralement, cela améliore les performances globales, mais peut parfois entraîner une dégradation des performances. Si défini, TCP ne mettra pas en cache les métriques à la fermeture des connexions.

Vérifiez avec

ethtool -k ethX

pour voir si le déchargement est activé ou non. Le déchargement du checksum TCP et le déchargement de gros segment sont pris en charge par la majorité des NIC Ethernet d'aujourd'hui et apparemment Broadcom le supporte également.

Essayez d'utiliser l'outil

powertop

lorsque le réseau est inactif et lorsque la saturation du réseau est atteinte. Cela montrera certainement si les interruptions du NIC sont à blâmer. Le polling de périphérique est une réponse à une telle situation. FreeBsd prend en charge le commutateur de polling directement à l'intérieur d'ifconfig mais linux n'a pas une telle option. Consultez ce lien pour activer le polling. Il est dit que BroadCom prend également en charge le polling, ce qui est une bonne nouvelle pour vous.

Ajuster les paquets jumbo pourrait ne pas convenir à vous puisque vous avez mentionné que votre trafic est principalement constitué de petits paquets. Mais essayez quand même !

3voto

GeorgeB Points 171

J'ai remarqué dans la liste des ajustements que les horodatages sont désactivés, s'il vous plaît ne faites pas cela. C'est un vieux retour aux jours d'antan où la bande passante était vraiment chère et les gens voulaient économiser quelques octets / paquet. C'est utilisé, par exemple, par la pile TCP de nos jours pour dire si un paquet arrivant pour un socket en "CLOSE_WAIT" est un ancien paquet pour la connexion ou s'il s'agit d'un nouveau paquet pour une nouvelle connexion et aide dans les calculs de RTT. Et économiser quelques octets pour un horodatage est RIEN comparé à ce que les adresses IPv6 vont ajouter. Désactiver les horodatages fait plus de mal que de bien.

Cette recommandation de désactiver les horodatages est juste un retour en arrière qui continue d'être transmis d'une génération de sysadmin à l'autre. Sorte d'un "légende urbaine" en quelque sorte.

2voto

Igor Points 845

Vous devez répartir la charge sur tous les cœurs de CPU. Démarrez 'irqbalance'.

2voto

avz2012 Points 49

Dans mon cas, seul un réglage unique :

net.ipv4.tcp_timestamps = 0

a apporté un changement très important et utile, le temps de chargement du site a diminué de 50%.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X