Amélioration des performances TCP sur un réseau gigabit avec beaucoup de connexions et un trafic élevé de petits paquets

J'essaie d'améliorer mon débit TCP sur un «réseau gigabit avec beaucoup de connexions et un trafic élevé de petits paquets». Le système d'exploitation de mon serveur est Ubuntu 11.10 Server 64bit.

Il y a environ 50 000 clients (et en croissance) connectés à mon serveur via TCP Sockets (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 conseiller les meilleures pratiques pour adapter le système d'exploitation à mes besoins?

Mon /etc/sysctl.congressemble à 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ÉE]

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

Quelques informations sur SACK: Quand désactiver TCP SACK?

Le problème est peut-être que votre carte réseau reçoit trop d’interruptions. Si la bande passante n'est pas le problème, la fréquence est le problème:

• Activer les tampons d'envoi / réception sur la carte réseau

  ethtool -g eth0
  

Vous montrera les paramètres actuels (256 ou 512 entrées). Vous pouvez probablement les porter à 1024, 2048 ou 3172. Plus n'a probablement aucun sens. Il s’agit simplement d’une mémoire tampon en anneau qui ne se remplit que si le serveur ne peut pas traiter les paquets entrants assez rapidement.

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

• Activez le contrôle de flux entrant / sortant sur le serveur et les ports de commutateur / routeur auxquels il est connecté.

  ethtool -a eth0
  

Sera probablement montrer:

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

Vérifiez / var / log / messages pour le paramètre actuel de eth0. Vérifiez quelque chose comme:

eth0: la liaison est active à 1 000 Mbits / s, en duplex intégral, en contrôle de flux tx et en rx

Si vous ne voyez pas tx et rx, vos administrateurs de réseau doivent ajuster les valeurs sur le commutateur / routeur. Sur Cisco, le contrôle de flux réception / transmission est activé.

Attention: si vous modifiez ces valeurs, votre lien descendra vers le haut pendant un temps très court (moins de 1).

• Si tout cela ne vous aide pas, vous pouvez également réduire la vitesse de la carte réseau à 100 Mbits (faites de même pour les ports 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 réseau.

Suivre ne serait peut-être pas la réponse définitive, mais des idées seront certainement avancées

Essayez de les ajouter à 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 tcp ack 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 cependant. Les avantages de la mise à l’échelle de la fenêtre sont décrits ici . En ce qui concerne la troisième option sysctl: par défaut, TCP enregistre diverses métriques de connexion dans le cache de routage lorsque la connexion se ferme, afin que les connexions établies dans un avenir proche puissent les utiliser pour définir les conditions initiales. Généralement, cela augmente les performances globales, mais peut parfois entraîner une dégradation des performances. Si défini, TCP ne mettra pas les métriques en cache lors de la fermeture des connexions.

Vérifier avec

ethtool -k ethX

pour voir si le déchargement est activé ou non. Le déchargement de la somme de contrôle TCP et le déchargement des segments volumineux sont pris en charge par la majorité des cartes réseau Ethernet actuelles et apparemment, Broadcom le prend également en charge.

Essayez d'utiliser un outil

powertop

lorsque le réseau est inactif et que la saturation du réseau est atteinte. Cela montrera certainement si les interruptions de la carte réseau sont le coupable. L'interrogation de périphérique est une réponse à une telle situation. FreeBsd prend en charge le commutateur d'interrogation directement dans ifconfig, mais Linux n'a pas cette option. Consultez -le pour activer l'interrogation. Il dit que BroadCom soutient également les sondages, ce qui est une bonne nouvelle pour vous.

Il se peut que le tweak de paquets volumineux ne le coupe pas pour vous puisque vous avez mentionné que votre trafic est constitué principalement de petits paquets. Mais hé l'essayer quand même!

vous devez répartir la charge sur tous les cœurs de la CPU. Commencez 'irqbalance'.

J'ai remarqué dans la liste des réglages que l'horodatage est désactivé, veuillez ne pas le faire. C'est un vieux retour en arrière lorsque la bande passante était vraiment chère et que les gens voulaient économiser quelques octets / paquet. Il est utilisé, par exemple, par la pile TCP ces jours-ci pour dire si un paquet arrivant pour une socket dans "CLOSE_WAIT" est un ancien paquet pour la connexion ou s'il s'agit d'un nouveau paquet pour une nouvelle connexion et facilite les calculs RTT. Et enregistrer les quelques octets pour un horodatage n’est RIEN comparer à ce que les adresses IPv6 vont ajouter. Désactiver les horodatages fait plus de mal que de bien.

Cette recommandation pour désactiver les horodatages est simplement un retour en arrière qui se répète continuellement d'une génération d'administrateur système à l'autre. Une sorte de "légende urbaine".

Je propose ceci:

kernel.sem = 350 358400 64 1024
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 4194304
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_adv_win_scale = 2
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_rmem = 4096 262144 4194304
net.ipv4.tcp_wmem = 4096 262144 4194304
net.ipv4.tcp_keepalive_time = 900
net.ipv4.tcp_keepalive_intvl = 900
net.ipv4.tcp_keepalive_probes = 9

Testé sur des serveurs Oracle DB sur RHEL et sur un logiciel de sauvegarde.

Dans mon cas, un seul tuninng:

net.ipv4.tcp_timestamps = 0

fait un changement très important et utile, le temps de chargement du site a été réduit de 50%.