Paramètres de performance réseau sous Linux

 (github.com/leandromoreira)
4 points par GN⁺ 2023-09-07 | 1 commentaires | Partager sur WhatsApp
  • Court tutoriel montrant où se trouvent les paramètres sysctl/réseau souvent utilisés dans le flux réseau de Linux
  • Des valeurs cargo cult capables d’offrir à la fois un débit élevé et une faible latence dans tous les cas ne sont pas réalistes ; les versions récentes du noyau ont des valeurs par défaut bien réglées, et les modifier peut nuire aux performances
  • Le chemin de réception est présenté comme un flux allant de la vérification MAC/FCS de la NIC, au DMA, au ring buffer de réception, à la hard IRQ, à NAPI, à la soft IRQ, à l’ingress qdisc, à netfilter, à la machine d’état TCP, au tampon de réception basé sur tcp_rmem, jusqu’à la lecture par l’application
  • Le chemin d’émission est présenté comme un flux allant de sendmsg côté application, à l’allocation de skb_buff, au tampon d’écriture du socket basé sur tcp_wmem, au traitement des en-têtes TCP/IP, à netfilter, à l’output qdisc basé sur txqueuelen, au transmit ring buffer, au DMA, jusqu’à l’IRQ de fin de transmission de la NIC
  • Les principaux éléments d’ajustement sont liés au traitement des rafales, à l’utilisation CPU, à la latence et à l’observation des pertes
    • Les ring buffers rx et tx sont des files destinées à absorber les rafales sans perte, mais leur augmentation peut accroître la latence
    • rx-usecs, tx-usecs, rx-frames, tx-frames définissent le temps d’attente et le nombre de trames avant le déclenchement d’une hard IRQ ; ils peuvent réduire l’utilisation CPU et le nombre de hard IRQ, et augmenter le débit au prix d’une latence plus élevée
    • netdev_budget_usecs, netdev_budget, dev_weight, netdev_max_backlog sont liés au cycle de polling NAPI et au débit de traitement de l’ingress qdisc
    • txqueuelen et default_qdisc sont liés à la file côté OUTPUT et à la discipline de mise en file par défaut
  • La vérification, la modification et la supervision s’appuient principalement sur ethtool, sysctl, ip, tc et les fichiers /proc
    • Exemple : vérifier le ring buffer avec ethtool -g ethX, le modifier avec ethtool -G ethX rx value tx value
    • Exemple : vérifier net.core.netdev_budget_usecs avec sysctl net.core.netdev_budget_usecs, le modifier avec sysctl -w net.core.netdev_budget_usecs value
    • Exemple : vérifier default_qdisc avec sysctl net.core.default_qdisc, superviser avec tc -s qdisc ls dev ethX
  • Les éléments liés aux tampons TCP couvrent tcp_rmem, tcp_wmem et tcp_moderate_rcvbuf ; si tcp_moderate_rcvbuf est défini, TCP tente d’ajuster automatiquement la taille du tampon de réception
  • Les éléments liés aux états TCP et au contrôle de congestion incluent net.core.somaxconn, tcp_fin_timeout, tcp_available_congestion_control, tcp_congestion_control, tcp_max_syn_backlog, tcp_syncookies, tcp_slow_start_after_idle
  • Le traçage réseau interne de Linux peut être observé avec perf, par exemple avec la commande perf trace --no-syscalls --event 'net:*' ping globo.com -c1 > /dev/null
  • Parmi les outils de test et de supervision proposés figurent iperf3, vegeta, netdata, ainsi que la combinaison prometheus + grafana + node exporter full dashboard

À lire aussi

1 commentaires

 
GN⁺ 2023-09-07
Avis de Hacker News

  • Avec les valeurs par défaut d’Ubuntu Linux, net.ipv4.tcp_rmem vaut environ 6 Mo, tandis que net.core.rmem_max vaut environ 1 Mo, ce qui crée une situation étrange
    Un socket TCP par défaut peut, si nécessaire, voir sa fenêtre de réception TCP monter jusqu’à 6 Mo, mais si une application en espace utilisateur appelle setsockopt SO_RCVBUF, même un socket qui pouvait déjà atteindre 6 Mo se retrouve limité à 1 Mo au maximum
    Même si l’on essaie de passer de 6 Mo à 4 Mo, on obtient 1 Mo, ce qui paraît très bizarre, et la même chose s’applique à SO_SNDBUF/wmem
    On dirait que Linux confond la priorité de ces options ; je me demande pourquoi core.rmem_max n’est pas réglé plus haut et utilisé comme directive faisant autorité, et s’il y a une raison historique à cela

    • Si le but est de limiter la quantité de données sur-bufferisées, on peut réduire TCP_NOTSENT_LOWAT au lieu de SO_SNDBUF/wmem
      Cette valeur limite la quantité de données supplémentaires mises en tampon au-delà de ce qui est nécessaire pour le produit bande passante-délai (BDP)
    • La valeur maximale de net.ipv4.tcp_rmem est la limite de l’auto-tuning effectué par le noyau
      Dès que SO_RCVBUF est défini, l’auto-tuning est désactivé pour ce socket, et net.core.rmem_max devient la valeur maximale
      C’est documenté assez clairement dans Documentation/networking/ip-sysctl.rst

  • Excellent, y compris le fait de montrer toutes les étapes par lesquelles passe un paquet après son arrivée sur la NIC jusqu’à l’espace utilisateur
    Pour ajouter un autre point lié aux performances réseau, sur les systèmes avec plusieurs CPU, il faut vérifier l’allocation NUMA, fréquente sur les gros serveurs
    Si la carte réseau est rattachée à un CPU et que l’application s’exécute sur un autre, cela peut aussi affecter les performances

  • Le simple fait de remplacer le contrôle de congestion par défaut de Linux, net.ipv4.tcp_congestion_control, par bbr peut faire une énorme différence dans certains cas
    Probablement surtout lorsqu’il y a de la distance, des pertes de paquets intermittentes, de la gigue et de l’encapsulation
    Au cours de l’année écoulée, j’ai débogué un problème dans le flux client host <-- HTTP --> reverse proxy host <-- HTTP over Wireguard --> service host : en moyenne, il était difficile de dépasser 20 % du débit maximal théorique, et les connexions finissaient avec le temps par ralentir au point de presque s’arrêter
    Après avoir utilisé des palliatifs consistant à fermer souvent les connexions de force, le passage du contrôle de congestion à bbr a donné un débit proche du maximum théorique et des connexions stables ; ce changement a été nécessaire des deux côtés de Wireguard

    • BBR se distingue par le fait qu’il n’utilise pas les pertes comme signal de congestion
      La plupart des piles TCP, dès qu’elles voient une première perte, divisent par deux la fenêtre d’envoi ou la réduisent fortement ; donc, sur un VPN avec des pertes, ou si l’on envoie de grosses rafales à 1 Gb/s vers un uplink VPN à 10 Mb/s, TCP observe des pertes et recule fortement
      BBR essaie de trouver la bande passante du goulot d’étranglement, mesure le temps aller-retour et augmente le débit d’envoi jusqu’à ce que le RTT augmente
      Lorsque le RTT augmente, il suppose qu’une file d’attente se forme au point le plus étroit du chemin, réduit le débit jusqu’à ce que la file se vide et que le RTT revienne à la normale, envoie à cette vitesse pendant un moment, puis tente de l’augmenter un peu à nouveau
      Il y a quelques années, même après être passé d’un uplink câble à 10 Mb/s à une fibre symétrique à 1 Gb/s, les uploads via le VPN de l’entreprise restaient bloqués autour de 5 Mb/s, ce qui était agaçant ; en passant sous FreeBSD à RACK TCP ou BBR, ils ont été multipliés par environ 8 pour atteindre la limite du VPN, autour de 40 Mb/s
    • BBRv1 est cassé, il ne faut donc pas l’utiliser sur l’Internet public
      Le tuning de performances façon copier-coller cargo cult, où l’on règle une valeur magique et tout s’améliore, est exactement l’inverse de ce que le texte original veut dire
      Heureusement, Google est en train d’intégrer BBRv3 en amont, donc cela devrait bientôt s’améliorer
    • Le contrôle de congestion fonctionne du côté qui envoie les données vers le côté qui les reçoit
      Si l’on veut seulement améliorer les performances dans un sens, il n’est pas nécessaire de modifier les deux côtés de Wireguard
      Je suis d’accord avec les autres commentaires au sujet de BBRv1, et l’implémentation de cubic du noyau Linux fonctionne plutôt bien pour la plupart des applications

  • Je me demande si le tuning des performances a aussi du sens pour les adaptateurs Wi‑Fi
    Sur desktop, je me demande aussi s’il existe un moyen de corriger les problèmes Ethernet des i210 et i225 autrement qu’en désactivant des fonctionnalités
    Ces deux-là semblent être les NIC les plus courantes aujourd’hui, et je ne comprends pas bien pourquoi du matériel réseau et des drivers aussi répandus ont autant de défauts
    Je m’intéresse beaucoup à RISC‑V, et je me dis qu’on pourrait peut-être commencer par une NIC entièrement ouverte et correcte
    Si elle est moins chère que l’i210, elle finira par être intégrée, même si c’est peut-être impossible

    • Si l’on peut sacrifier 10 à 20 % du débit maximal du réseau local, on peut fortement améliorer l’équité Wi‑Fi, améliorer les temps de ping et réduire le bufferbloat
      Cela dit, en Wi‑Fi, des pics de ping aléatoires se produisent toujours
      Il y a un gros fil sur https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/590... qui traite de l’activation et du tuning de l’AQM, ainsi que des compromis entre débit et latence
    • L’i225 est tout simplement un produit cassé, mais l’i210 offre d’excellentes performances
      Sur les CPU de la même époque, 1 Gb n’a rien de très difficile, et l’i210 fournit 4 files
      Je me demande ce que tu reproches à l’i210
    • J’utilisais une carte mère avec un i225 intégré, et j’ai réglé le problème en achetant une PCIe I350

  • L’aperçu illustré des files réseau Linux est excellent, au point que j’aimerais l’afficher quelque part sur un mur
    Le livre Systems Performance de Brendan couvre aussi très bien les performances réseau Linux, entre autres, et il en est déjà à sa 2e édition
    Les deux éditions sont excellentes, mais la 2e se concentre surtout sur Linux, tandis que la 1re inclut aussi Solaris
    Plus récemment, il y a aussi le livre BPF Performance Tools du même auteur
    [1] Systems Performance: Enterprise and the Cloud, 2nd Edition (2020)
    https://www.brendangregg.com/systems-performance-2nd-edition...
    [2] BPF Performance Tools:
    https://www.brendangregg.com/bpf-performance-tools-book.html

  • Rien que parcourir l’article était agréable, et la recherche comme la structure sont très bonnes
    Cela dit, je me demande qui, concrètement, tune régulièrement les paramètres réseau Linux

  • Ce document devrait sans doute indiquer quelque part qu’il s’agit de TCP
    Le contenu est très centré sur des préoccupations liées à TCP, et c’est utile puisque les gens utilisent surtout TCP
    Mais les valeurs de tuning par défaut d’UDP sont ridiculement basses, et cette partie manque de façon assez visible

    • Je me demande s’il existe de bonnes ressources sur le tuning UDP

  • J’aimerais qu’on me recommande des vidéos ou des séries traitant de sujets similaires
    Il existe beaucoup de ressources générales sur le networking, mais j’ai eu du mal à trouver des ressources sur l’implémentation concrète dans Linux

    • Il faudrait aussi le même type de ressources du point de vue des microcontrôleurs
      J’aimerais essayer de créer un serveur d’écho TCP simple pour microcontrôleur, mais la plupart des exemples se contentent d’utiliser la bibliothèque TCP propre au fournisseur et expliquent très peu le processus de configuration et d’établissement d’une connexion directe avec un routeur