Linux-Netzwerk-Performance-Parameter

 (github.com/leandromoreira)
4 Punkte von GN⁺ 2023-09-07 | 1 Kommentare | Auf WhatsApp teilen
  • Kurzes Tutorial, das zeigt, wo sich häufig verwendete sysctl-/Netzwerk-Parameter im Linux-Netzwerkpfad befinden
  • Cargo-Cult-Werte, die in allen Situationen zugleich hohen Durchsatz und niedrige Latenz liefern, sind nicht realistisch; aktuelle Kernel-Versionen haben gut abgestimmte Standardwerte, und Änderungen an den Defaults können die Performance verschlechtern
  • Der Empfangspfad wird als Ablauf von der MAC-/FCS-Prüfung der NIC über DMA, den Receive-Ring Buffer, Hard IRQ, NAPI, Soft IRQ, Ingress-qdisc, netfilter, die TCP-Statusmaschine, den auf tcp_rmem basierenden Empfangspuffer bis zum Lesen durch die Anwendung beschrieben
  • Der Sendepfad wird als Ablauf von sendmsg in der Anwendung über die Zuweisung von skb_buff, den auf tcp_wmem basierenden Socket-Schreibpuffer, die TCP/IP-Header-Verarbeitung, netfilter, den auf txqueuelen basierenden Output-qdisc, den Transmit Ring Buffer, DMA bis zum IRQ für abgeschlossene NIC-Übertragungen beschrieben
  • Zentrale Tuning-Punkte hängen mit Burst-Verarbeitung, CPU-Auslastung, Latenz und der Beobachtung von Drops zusammen
    • rx- und tx-Ring Buffer sind Queues, um Verbindungs-Bursts ohne Drops aufzunehmen; eine Vergrößerung kann die Latenz erhöhen
    • rx-usecs, tx-usecs, rx-frames, tx-frames bestimmen Wartezeit und Frame-Anzahl vor dem Auslösen von Hard IRQs; damit lassen sich CPU-Nutzung und Hard IRQs reduzieren und auf Kosten der Latenz der Durchsatz steigern
    • netdev_budget_usecs, netdev_budget, dev_weight, netdev_max_backlog beziehen sich auf den NAPI-Polling-Zyklus und den Durchsatz des Ingress-qdisc
    • txqueuelen und default_qdisc betreffen die Queue auf der OUTPUT-Seite und die standardmäßige Queuing Discipline
  • Prüfen, Ändern und Monitoring konzentrieren sich auf ethtool, sysctl, ip, tc und /proc-Dateien
    • Beispiel: Ring Buffer prüfen mit ethtool -g ethX, ändern mit ethtool -G ethX rx value tx value
    • Beispiel: net.core.netdev_budget_usecs prüfen mit sysctl net.core.netdev_budget_usecs, ändern mit sysctl -w net.core.netdev_budget_usecs value
    • Beispiel: default_qdisc prüfen mit sysctl net.core.default_qdisc, Monitoring mit tc -s qdisc ls dev ethX
  • Die TCP-Puffer-Einträge behandeln tcp_rmem, tcp_wmem und tcp_moderate_rcvbuf; wenn tcp_moderate_rcvbuf gesetzt ist, versucht TCP, die Größe des Empfangspuffers automatisch anzupassen
  • Zusammen mit TCP-Status und Staukontrolle werden net.core.somaxconn, tcp_fin_timeout, tcp_available_congestion_control, tcp_congestion_control, tcp_max_syn_backlog, tcp_syncookies und tcp_slow_start_after_idle erläutert
  • Internes Netzwerk-Tracking in Linux lässt sich mit perf prüfen; ein Beispielbefehl hat die Form perf trace --no-syscalls --event 'net:*' ping globo.com -c1 > /dev/null
  • Als Test- und Monitoring-Tools werden iperf3, vegeta, netdata, prometheus + grafana + node exporter full dashboard vorgeschlagen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-09-07
Meinungen auf Hacker News

  • In den Standardwerten von Ubuntu Linux liegt net.ipv4.tcp_rmem bei etwa 6 MB, net.core.rmem_max aber bei etwa 1 MB, was zu einer merkwürdigen Situation führt.
    Ein normaler TCP-Socket kann sein TCP-Empfangsfenster bei Bedarf auf bis zu 6 MB vergrößern, aber wenn eine Userspace-App setsockopt SO_RCVBUF aufruft, wird selbst ein Socket, der bereits 6 MB nutzen konnte, auf maximal 1 MB begrenzt.
    Selbst wenn man von 6 MB auf 4 MB reduzieren will, landet man bei 1 MB; das wirkt sehr seltsam, und dasselbe gilt für SO_SNDBUF/wmem.
    Es sieht so aus, als würde Linux die Prioritäten dieser Optionen durcheinanderbringen. Ich frage mich, warum man core.rmem_max nicht größer setzt und als maßgebliche Vorgabe verwendet, und ob es dafür historische Gründe gibt.

    • Wenn es darum geht, die Menge übermäßig gepufferter Daten zu begrenzen, kann man statt SO_SNDBUF/wmem TCP_NOTSENT_LOWAT niedriger setzen.
      Dieser Wert begrenzt die zusätzliche Pufferung über die Menge hinaus, die für das Bandbreiten-Verzögerungs-Produkt (BDP) erforderlich ist.
    • Der Maximalwert von net.ipv4.tcp_rmem ist die Grenze des vom Kernel durchgeführten Autotunings.
      Sobald man SO_RCVBUF setzt, wird das Autotuning für diesen Socket deaktiviert, und net.core.rmem_max wird zum Maximalwert.
      Das ist in Documentation/networking/ip-sysctl.rst ziemlich klar dokumentiert.

  • Ausgezeichnet, auch weil alle Schritte gezeigt werden, die ein Paket vom Eintritt in die NIC bis in den Userspace durchläuft.
    Eine weitere Ergänzung zur Netzwerk-Performance: Auf Systemen mit mehreren CPUs sollte man die NUMA-Zuordnung prüfen, wie sie bei großen Servern üblich ist.
    Wenn die Netzwerkkarte an einer CPU-Seite hängt und die Anwendung auf einer anderen CPU läuft, kann das ebenfalls die Performance beeinflussen.

  • Schon das Umstellen der standardmäßigen Linux-Staukontrolle net.ipv4.tcp_congestion_control auf bbr kann in manchen Situationen einen enormen Unterschied machen.
    Vermutlich gilt das besonders bei größerer Entfernung, sporadischem Paketverlust und Jitter sowie bei Kapselung.
    Im vergangenen Jahr habe ich ein Problem in einem Ablauf client host <-- HTTP --> reverse proxy host <-- HTTP over Wireguard --> service host debuggt; im Durchschnitt waren kaum mehr als 20 % des theoretischen Maximaldurchsatzes erreichbar, und die Verbindung wurde mit der Zeit fast bis zum Stillstand langsam.
    Nachdem ich als Workaround Verbindungen häufig zwangsweise geschlossen hatte, stellte ich die Staukontrolle auf bbr um; danach gab es nahezu theoretischen Maximaldurchsatz und stabile Verbindungen. Diese Änderung war auf beiden Wireguard-Seiten nötig.

    • BBR unterscheidet sich dadurch, dass es Verlust nicht als Stausignal verwendet.
      Die meisten TCP-Stacks halbieren das Sendefenster oder senken es stark, sobald erstmals Verlust sichtbar wird. Wenn man also ein VPN mit Verlusten hat oder auf einen 10-Mb/s-VPN-Uplink große Bursts mit 1 Gb/s sendet, sieht TCP Verlust und zieht sich stark zurück.
      BBR versucht, die Engpassbandbreite zu finden, misst die Round-Trip-Zeit und erhöht die Senderate, bis die RTT steigt.
      Wenn die RTT steigt, nimmt es an, dass sich am engsten Abschnitt des Pfads eine Queue bildet, senkt die Senderate, bis die Queue abgebaut ist und die RTT wieder normal wird, sendet dann eine Weile mit dieser Geschwindigkeit und versucht anschließend, sie wieder etwas anzuheben.
      Vor einigen Jahren wechselte ich von einem 10-Mb/s-Kabel-Uplink auf eine symmetrische Glasfaserleitung mit 1 Gb/s, aber der Upload ins Firmen-VPN blieb frustrierenderweise bei etwa 5 Mb/s hängen. Nach dem Wechsel auf RACK TCP oder BBR unter FreeBSD stieg er um etwa den Faktor 8 bis an die VPN-Grenze von rund 40 Mb/s.
    • BBRv1 ist kaputt, daher sollte man es im öffentlichen Internet nicht verwenden.
      Copy-Paste-Performance-Tuning nach dem Cargo-Cult-Motto, dass alles besser wird, wenn man nur einen magischen Wert setzt, ist das genaue Gegenteil dessen, was der Originaltext sagen will.
      Zum Glück upstreamt Google BBRv3, daher dürfte es bald besser werden.
    • Staukontrolle wirkt in der Richtung vom Sender zum Empfänger.
      Wenn man nur die Performance in einer Richtung verbessern will, muss man nicht beide Wireguard-Seiten ändern.
      Zu BBRv1 stimme ich den anderen Meinungen zu, und die cubic-Implementierung im Linux-Kernel funktioniert für die meisten Anwendungen ziemlich gut.

  • Ich frage mich, ob Performance-Tuning auch bei Wi‑Fi-Adaptern sinnvoll ist.
    Außerdem frage ich mich, ob es auf Desktops außer dem Abschalten von Funktionen eine Möglichkeit gibt, die Ethernet-Probleme von i210 und i225 zu beheben.
    Diese beiden scheinen heutzutage die häufigsten NICs zu sein, aber ich verstehe nicht recht, warum gängige Netzwerkhardware und Treiber so viele Mängel haben.
    Ich interessiere mich sehr für RISC‑V und frage mich, ob man nicht mit einer vollständig offenen und korrekt funktionierenden NIC anfangen sollte.
    Wenn sie günstiger als der i210 wäre, würde man sie am Ende wohl verbauen, aber vielleicht ist das auch unmöglich.

    • Wenn man 10–20 % des maximalen lokalen Netzwerkdurchsatzes opfern kann, lässt sich die Wi‑Fi-Fairness stark erhöhen, die Ping-Zeiten verbessern und Bufferbloat reduzieren.
      Allerdings treten bei Wi‑Fi weiterhin zufällige Ping-Spitzen auf.
      Unter https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/590... gibt es einen großen Thread über das Aktivieren und Tunen von AQM sowie über den Kompromiss zwischen Durchsatz und Latenz.
    • i225 ist einfach kaputt, aber mit dem i210 bekommt man hervorragende Leistung.
      1 Gb ist für CPUs aus derselben Zeit auch keine besonders große Herausforderung, und der i210 bietet 4 Queues.
      Ich frage mich, was genau dich am i210 stört.
    • Ich hatte ein Mainboard mit onboard i225 und habe das Problem gelöst, indem ich eine PCIe I350 gekauft habe.

  • Die grafische Übersicht der Linux-Netzwerk-Queues ist so gut, dass ich sie mir irgendwo an die Wand hängen möchte.
    Brendans Buch „Systems Performance“ behandelt ebenfalls Linux-Netzwerk-Performance und Ähnliches sehr gut; es ist inzwischen bereits in der 2. Auflage erschienen.
    Beide Auflagen sind hervorragend, aber die 2. konzentriert sich hauptsächlich auf Linux, während die 1. auch Solaris umfasst.
    Neuerdings gibt es vom selben Autor auch das Buch „BPF Performance Tools“.
    [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

  • Schon das Überfliegen des Artikels hat Spaß gemacht; Recherche und Aufbau sind sehr gut.
    Allerdings frage ich mich, wer tatsächlich regelmäßig Linux-Netzwerkparameter tunt.

  • Dieses Dokument sollte wohl irgendwo ausdrücklich TCP erwähnen.
    Der Inhalt konzentriert sich stark auf TCP-bezogene Themen, und da die meisten Leute hauptsächlich TCP verwenden, ist das durchaus nützlich.
    Die Standardwerte für UDP-Tuning sind jedoch miserabel niedrig, und dieser Teil fehlt hier auffällig.

    • Ich frage mich, ob es gute Ressourcen zu UDP-Tuning gibt.

  • Ich würde mich über Empfehlungen für Videos oder Serien freuen, die ähnliche Inhalte behandeln.
    Allgemeine Networking-Ressourcen gibt es viele, aber Material zur konkreten Implementierung unter Linux war schwer zu finden.

    • Aus Sicht von Mikrocontrollern bräuchte ich ebenfalls solche Ressourcen.
      Ich würde gern einen einfachen TCP-Echo-Server für einen Mikrocontroller bauen, aber die meisten Beispiele verwenden nur die herstellereigene TCP-Bibliothek und erklären kaum, wie man eine Verbindung zu einem Router direkt einrichtet und aufbaut.