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

Solution 1 :

Le problème peut ê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 :

• 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 pas de 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
  

Affichera probablement :

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

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

eth0 :le lien est à 1 000 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 sur lequel le contrôle de flux de réception/transmission est activé.

Attention : La modification de ces valeurs entraînera l'arrêt et le retour de votre lien pendant une très courte période (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 - augmentez les tampons de réception dans le tampon circulaire de la carte réseau.

Solution 2 :

Ce qui suit n'est peut-être pas la réponse définitive, mais il proposera certainement des 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

Alors que l'accusé de réception TCP sélectif est bon pour des performances optimales dans le cas d'un réseau à large bande passante. Mais attention aux 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 enregistre diverses métriques de connexion dans le cache de route lorsque la connexion se ferme, afin que les connexions établies dans un proche avenir puissent les utiliser pour définir les conditions initiales. En règle générale, 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 métriques lors de la fermeture des connexions.

Vérifiez avec

ethtool -k ethX

pour voir si le déchargement est activé ou non. Le déchargement de somme de contrôle TCP et le déchargement de 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 l'outil

powertop

lorsque le réseau est inactif et lorsque la saturation du réseau est atteinte. Cela montrera certainement si les interruptions NIC sont le coupable. L'interrogation de l'appareil 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. Il indique que BroadCom prend également en charge les sondages, ce qui est une bonne nouvelle pour vous.

Le réglage des paquets Jumbo pourrait ne pas vous convenir, car vous avez mentionné que votre trafic est principalement constitué de petits paquets. Mais bon, essayez quand même !

Solution 3 :

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 à l'époque où la bande passante était très chère et où 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 enregistrer les quelques octets pour un horodatage n'est RIEN comparé à 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 n'est qu'un retour en arrière qui est transmis d'une génération d'administrateur système à la suivante. Une sorte de "légende urbaine".

Solution 4 :

vous devez répartir la charge sur tous les cœurs du processeur. Lancez 'irqbalance'.

Solution 5 :

Dans mon cas un seul réglage :

net.ipv4.tcp_timestamps = 0

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