Amélioration des performances TCP sur un réseau gigabit avec de nombreuses connexions et un trafic élevé de petits paquets
J'essaie d'améliorer mon TCP débit sur un "réseau gigabit avec beaucoup de connexions et un trafic élevé de petits paquets". Mon OS de serveur est Ubuntu 11.10 Server 64bit.
Il y a environ 50 000 clients (et de plus en plus) 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 TCP et charge utile). Les 5% restants varient de 150 à 4096+ octets.
Avec la configuration ci-dessous, mon serveur peut gérer le trafic jusqu'à 30 Mbps (duplex intégral).
Pouvez-vous me conseiller les meilleures pratiques pour régler le système d'exploitation en fonction de mes besoins?
Ma /etc/sysctl.cong ressemble à ça:
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 désactivé?
Le problème peut être que vous obtenez 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:
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 augmenter à 1024, 2048 ou 3172. Plus n'a probablement aucun sens. Il s'agit simplement d'un tampon en anneau qui ne se remplit que si le serveur n'est pas en mesure de traiter les paquets entrants assez rapidement.
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 entrant/sortant sur le serveur et les ports de commutateur/routeur auxquels il est connecté.
ethtool -a eth0
Montrera probablement:
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 à 1000 Mbps, duplex intégral, 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, le contrôle de flux de réception/transmission est activé.
Méfiez-vous: La modification de ces valeurs fera descendre et monter votre lien pendant très peu de temps (moins de 1 s).
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 sur les ports du commutateur/routeur)
ethtool -s eth0 autoneg off && ethtool -s eth0 speed 100
Mais dans votre cas, je dirais - élevez les tampons de réception dans le tampon en anneau NIC.
La suite n'est peut-être pas la réponse définitive, mais elle proposera certainement quelques idé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
Bien que le tcp ack sélectif soit bon pour des performances optimales dans le cas d'un réseau à large bande passante. Mais attention aux autres inconvénients cependant. Les avantages de la mise à l'échelle des fenêtres 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 route lorsque la connexion se ferme, de sorte que les connexions établies dans un avenir proche puissent les utiliser pour définir les conditions initiales. Habituellement, cela augmente les performances globales, mais peut parfois entraîner une dégradation des performances. S'il est défini, TCP ne mettra pas en cache les mesures à la fermeture des connexions.
Vérifier avec
ethtool -k ethX
pour voir si le déchargement est activé ou non. déchargement de la somme de contrôle TCP et le déchargement de gros segments sont pris en charge par la majorité des cartes réseau Ethernet actuelles et apparemment Broadcom le prend également en charge.
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 NIC les interruptions sont le coupable. L'interrogation du 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 une telle option. Consultez ceci pour activer l'interrogation. Cela signifie que BroadCom prend également en charge l'interrogation, ce qui est une bonne nouvelle pour vous.
Jumbo packet Tweak pourrait ne pas le couper pour vous puisque vous avez mentionné que votre trafic se compose principalement de petits paquets. Mais bon essayez quand même!
Dans mon cas, un seul tuninng:
net.ipv4.tcp_timestamps = 0
a fait un changement très important et utile, le temps de chargement du site a diminué de 50%.
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 les serveurs Oracle DB sur RHEL et dans les logiciels de sauvegarde.
J'ai remarqué dans la liste des réglages que les horodatages étaient désactivés, veuillez ne pas le faire. C'est un vieux retour aux jours d'autrefois où la bande passante était vraiment chère et 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 un 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 aide dans les calculs RTT. Et économiser les quelques octets pour un horodatage n'est RIEN par rapport à ce que les adresses IPv6 vont ajouter. La désactivation des horodatages fait plus de mal que de bien.
Cette recommandation de désactivation des horodatages n'est qu'un retour en arrière qui continue de se transmettre d'une génération d'administrateur système à la suivante. Une sorte de "légende urbaine".
vous devez répartir la charge sur tous les cœurs de processeur. Démarrez "irqbalance".