Jumbo Frames unter Linux: MTU-Tuning fuer die Datenbank-Netzwerkverbindung

1. Warum Jumbo Frames fuer Datenbank-Traffic relevant sind

Die Standard-MTU (Maximum Transmission Unit) von Ethernet betraegt 1500 Byte. Jedes IP-Paket, das ueber die Netzwerkkarte verschickt wird, traegt zusaetzlich einen Overhead aus Ethernet-, IP- und TCP-Headern von etwa 54 Byte. Bei einer MySQL-Replikation, einem grossen Backup-Transfer oder dem Massenexport von Produktdaten zwischen Webserver und Datenbankserver bedeutet das: Fuer jede uebertragene Nutzlast von 1446 Byte muss der Kernel ein komplettes Paket mit Header aufbauen, in die Warteschlange der Netzwerkkarte legen und per Interrupt behandeln. Jumbo Frames erhoehen die MTU auf typischerweise 9000 Byte und reduzieren damit die Anzahl der Pakete, die fuer dieselbe Datenmenge noetig sind, um den Faktor sechs.

Fuer eine Magento-Installation mit getrenntem Applikations- und Datenbankserver zaehlt dieser Unterschied besonders bei Batch-Operationen: taeglichen Backups, Indexer-Laeufen mit grossen Resultsets, Redis-Replikation oder dem naechtlichen Abgleich von Preis- und Bestandsdaten aus einem ERP-System. Bei interaktiven Webrequests mit kleinen Antworten faellt der Effekt von Jumbo Frames kaum ins Gewicht, weil dort ohnehin selten die volle MTU ausgenutzt wird. Der Nutzen entsteht bei grossen, sequenziellen Datenstroemen zwischen zwei Servern im selben internen Netzsegment, nicht bei jedem beliebigen Traffic im Stack.

Wichtig fuer die Einordnung: Jumbo Frames sind kein Ersatz fuer eine schnelle Anbindung, sondern eine Effizienzoptimierung der vorhandenen Bandbreite. Wer bereits an der Kapazitaetsgrenze der Netzwerkkarte oder des Switch-Uplinks arbeitet, gewinnt durch eine hoehere MTU spuerbar CPU-Entlastung, weil weniger Interrupts pro uebertragenem Megabyte anfallen. Wer dagegen unter 100 MBit/s Traffic zwischen Web- und Datenbankserver liegt, wird den Unterschied kaum in Benchmarks sehen.

2. MTU-Grundlagen: Ethernet-Frames und Header-Overhead

Bevor Jumbo Frames konfiguriert werden, hilft ein kurzer Blick auf die tatsaechliche Zusammensetzung eines Ethernet-Frames: 14 Byte Ethernet-Header, bis zu 60 Byte IP-Header inklusive Optionen, 20 Byte TCP-Header und schliesslich die Nutzlast. Bei MTU 1500 verbleiben nach diesem Overhead im Schnitt etwas mehr als 1400 Byte fuer Anwendungsdaten, bei MTU 9000 sind es entsprechend fast 8900 Byte, ohne dass sich der fixe Header-Anteil pro Paket veraendert.

Der Begriff MTU beschreibt die groesste Nutzlast, die ein einzelner Ethernet-Frame transportieren darf, ohne dass der Kernel das Paket fragmentiert. Bei der Standard-MTU von 1500 Byte bleiben nach Abzug von Ethernet-Header, IP-Header und TCP-Header rund 1460 Byte fuer die eigentlichen Anwendungsdaten. Erhoeht man die MTU auf 9000 Byte, wie es bei Jumbo Frames ueblich ist, bleiben etwa 8960 Byte Nutzlast pro Frame uebrig. Der relative Overhead sinkt dadurch von rund 3,6 Prozent auf unter 0,5 Prozent der uebertragenen Daten.

Fuer den Linux-Kernel bedeutet eine hoehere MTU vor allem weniger Arbeit pro uebertragenem Megabyte: weniger Aufrufe des Netzwerktreibers, weniger Interrupts, weniger Kontextwechsel zwischen Kernel- und Userspace fuer denselben Datenstrom. Auf Servern mit hoher Netzwerklast, etwa bei einer permanenten MySQL-Master-Slave-Replikation oder einem staendigen Datenaustausch mit einem Elasticsearch-Cluster, summiert sich dieser Effekt ueber den Tag zu einer messbaren CPU-Entlastung. Jumbo Frames wirken damit vor allem als CPU-Optimierung, nicht in erster Linie als reine Bandbreitensteigerung.

# Show current MTU for all interfaces
ip link show | grep -E "^[0-9]+:|mtu"

# Typical output for a standard interface
# 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP

# Show MTU including the internal network interface used for DB traffic
ip -d link show eth1

3. Wann Jumbo Frames tatsaechlich etwas bringen

Diese Einschraenkung ist zentral fuer eine realistische Erwartungshaltung, bevor ein Team Zeit in die Umstellung investiert. Wer den Nutzen von Jumbo Frames vorab grob abschaetzen will, sollte pruefen, wie viel Traffic tatsaechlich innerhalb des eigenen Rechenzentrums oder VLANs fliesst, statt sich an theoretischen Benchmark-Zahlen aus fremden Umgebungen mit anderer Hardware und Topologie zu orientieren.

Der haeufigste Fehler beim Thema Jumbo Frames ist die pauschale Annahme, eine hoehere MTU beschleunige automatisch jede Netzwerkverbindung. Tatsaechlich zeigt sich der Nutzen fast ausschliesslich bei grossen, sequenziellen Datenmengen innerhalb desselben Layer-2-Segments: MySQL-Replikationsstreams, rsync-Backups, NFS-Mounts fuer geteilte Medien-Verzeichnisse oder die interne Kommunikation zwischen Applikationsserver und einem Suchindex-Cluster. Bei diesen Workloads verschiebt sich der Flaschenhals oft weg von der reinen Bandbreite hin zur CPU-Zeit, die fuer die Paketverarbeitung aufgewendet wird, und genau dort setzen Jumbo Frames an.

Fuer den Traffic zwischen Endnutzer-Browser und Webserver ueber das oeffentliche Internet sind Jumbo Frames dagegen nicht relevant und auch nicht konfigurierbar, weil die MTU auf dem gesamten Pfad durch das Internet von Routern kontrolliert wird, auf die man keinen Einfluss hat. Der Vorteil von Jumbo Frames beschraenkt sich also auf selbst kontrollierte interne Netze: das Rack im eigenen Rechenzentrum, ein privates VLAN zwischen Applikations- und Datenbankserver oder ein dediziertes Storage-Netzwerk fuer Backups. Wer diese Abgrenzung nicht macht und versucht, die externe MTU zu erhoehen, produziert nur Fehlkonfigurationen ohne jeden Nutzen.

Ein weiterer Aspekt bei der Entscheidung fuer Jumbo Frames ist die Art der Virtualisierung. Bei KVM- oder Xen-basierten virtuellen Maschinen mit einer virtio-Netzwerkkarte laesst sich die MTU meist problemlos erhoehen, weil der Hypervisor die volle Kontrolle ueber das virtuelle Netzwerksegment hat. Bei containerisierten Setups mit Docker-Bridge-Netzwerken muss dagegen zusaetzlich die MTU der Bridge selbst angepasst werden, da sonst der Container weiterhin auf 1500 Byte begrenzt bleibt, selbst wenn der Host-Kernel Jumbo Frames unterstuetzt.

Eine dritte Kategorie, in der Jumbo Frames haeufig unterschaetzt werden, sind Storage-Netzwerke fuer iSCSI oder NFS, ueber die etwa geteilte Media-Verzeichnisse mehrerer Magento-Webserver in einer Cluster-Umgebung eingebunden werden. Da hier durchgaengig grosse Dateien uebertragen werden, etwa Produktbilder oder generierte Cache-Dateien, profitieren diese Verbindungen von einer hoeheren MTU in aehnlichem Masse wie MySQL-Replikation, oft sogar staerker, weil NFS-Traffic tendenziell noch sequenzieller ablaeuft als typischer Datenbank-Traffic.

4. MTU unter Linux pruefen und dauerhaft aendern

Die MTU eines Interfaces laesst sich unter Linux mit ip link set dev eth1 mtu 9000 sofort aendern, allerdings nur temporaer bis zum naechsten Neustart oder Netzwerk-Reload. Fuer eine dauerhafte Konfiguration muss der Wert in die persistente Netzwerkkonfiguration eingetragen werden, bei modernen Distributionen ueblicherweise ueber systemd-networkd oder Netplan. Vor jeder Aenderung sollte geprueft werden, ob die Netzwerkkarte selbst Jumbo Frames unterstuetzt, denn nicht jede virtuelle NIC in Cloud-Umgebungen erlaubt eine MTU ueber 1500 Byte ohne separate Konfiguration beim Hosting-Anbieter.

Ein haeufig uebersehener Punkt: Die maximale MTU einer Netzwerkkarte laesst sich mit ip link show eth1 im Feld maxmtu auslegen, aber viele Cloud-Anbieter deckeln virtuelle Interfaces standardmaessig auf 1500 Byte, selbst wenn die zugrunde liegende Hardware mehr erlauben wuerde. Bei dedizierten Servern und selbst betriebener Hardware ist die Konfiguration dagegen vollstaendig selbst steuerbar, solange auch der Switch mitspielt, wie im naechsten Abschnitt beschrieben.

# /etc/netplan/01-internal-db-network.yaml
network:
  version: 2
  ethernets:
    eth1:
      mtu: 9000
      addresses:
        - 10.0.1.10/24
      # This interface connects to the internal DB/replication VLAN only

5. Ende-zu-Ende-Konsistenz: Switch, NIC und alle Hosts im Pfad

Der kritischste Punkt bei Jumbo Frames ist die Konsistenz ueber den gesamten Pfad hinweg. Eine hoehere MTU nur auf dem Webserver zu setzen, waehrend der Datenbankserver bei 1500 Byte bleibt oder der dazwischenliegende Switch keine Jumbo Frames weiterleitet, fuehrt nicht zu einem Fehler, sondern zu stillem Paketverlust oder unnoetiger Fragmentierung. TCP verhandelt die maximale Segmentgroesse (MSS) zwar automatisch beim Verbindungsaufbau, aber nur, wenn Path MTU Discovery entlang des gesamten Pfads funktioniert, was in vielen internen Netzen mit blockierten ICMP-Nachrichten nicht der Fall ist.

Vor der Umstellung auf Jumbo Frames muss deshalb jedes Geraet im Pfad geprueft werden: die Netzwerkkarten von Web- und Datenbankserver, alle beteiligten Switch-Ports inklusive deren eigener Jumbo-Frame-Konfiguration und, falls vorhanden, ein dazwischenliegender Load Balancer oder eine Firewall-Appliance. Ein einziges Geraet mit MTU 1500 im Pfad reicht aus, um die gesamte Optimierung wirkungslos zu machen oder, schlimmer, zu Verbindungsabbruechen bei grossen Paketen zu fuehren, die nicht fragmentiert werden koennen, weil das DF-Bit (Don't Fragment) gesetzt ist.

In der Praxis empfiehlt sich deshalb ein schrittweises Vorgehen: zuerst die MTU auf einem isolierten Testsegment mit zwei Servern erhoehen, die Konnektivitaet vollstaendig validieren, und erst danach die Konfiguration auf weitere Produktivserver ausrollen. Ein zentrales Configuration-Management-Werkzeug wie Ansible oder Puppet stellt dabei sicher, dass die MTU-Einstellung auf allen betroffenen Hosts synchron bleibt und nicht durch manuelle Einzelaenderungen auseinanderlaeuft, was in gewachsenen Infrastrukturen die haeufigste Ursache fuer inkonsistente Jumbo Frames ist.

6. Path MTU Discovery und Fragmentierungsprobleme diagnostizieren

Path MTU Discovery (PMTUD) ist der Mechanismus, mit dem TCP-Verbindungen automatisch die kleinste MTU entlang eines Netzwerkpfads ermitteln. Sendet ein Host ein Paket, das zu gross fuer ein Zwischen-Geraet ist, und ist das DF-Bit gesetzt, antwortet der Router idealerweise mit einer ICMP-Nachricht vom Typ "Fragmentation Needed". Viele Firewalls und Sicherheitsrichtlinien blockieren jedoch pauschal ICMP-Traffic, was PMTUD funktionslos macht und zu einem klassischen Symptom fuehrt: kleine Requests funktionieren einwandfrei, aber Verbindungen mit groesseren Datenmengen haengen sich scheinbar zufaellig auf.

Das Kommando ping -M do -s 8972 datenbankserver testet gezielt, ob ein Paket mit einer bestimmten Groesse ohne Fragmentierung durchkommt. Schlaegt der Test fehl, obwohl die MTU auf beiden Endpunkten korrekt auf 9000 Byte gesetzt ist, liegt das Problem fast immer an einem Zwischen-Geraet mit niedrigerer MTU oder an blockierten ICMP-Paketen. tracepath ist in diesem Fall das naechste Diagnosewerkzeug, weil es die tatsaechliche Pfad-MTU Hop fuer Hop ermittelt und genau den Punkt zeigt, an dem die MTU sinkt.

# Test if a 9000-byte MTU path works end to end without fragmentation
# 8972 = 9000 - 28 (ICMP + IP header)
ping -M do -s 8972 -c 3 10.0.1.20

# If this fails, find the exact hop where MTU drops
tracepath 10.0.1.20

# Verify current MTU-related TCP behavior for an active connection
ss -i dst 10.0.1.20 | grep -E "mss|cwnd"

Ein weiteres Diagnosewerkzeug ist mtr (My Traceroute), das kontinuierlich Pakete entlang eines Pfads sendet und Paketverlust pro Hop in Echtzeit anzeigt. Bei Verdacht auf sporadische Fragmentierungsprobleme, die sich nicht mit einem einzelnen ping-Aufruf reproduzieren lassen, liefert mtr ueber mehrere Minuten hinweg ein deutlich klareres Bild als einzelne Stichproben. Gerade bei intermittierenden Problemen, die nur unter Last auftreten, ist diese kontinuierliche Beobachtung oft der einzige Weg, das betroffene Geraet im Pfad zuverlaessig zu identifizieren.

7. Auswirkungen auf MySQL-Replikation und Backup-Transfers messen

Bevor eine Umstellung auf Jumbo Frames produktiv ausgerollt wird, sollte der Effekt mit einem realistischen Workload gemessen werden, statt sich auf theoretische Prozentwerte zu verlassen. Ein einfacher, aber aussagekraeftiger Test ist die Zeitmessung eines vollstaendigen mysqldump-Transfers oder eines rsync-Laufs mit den tatsaechlichen Datenmengen der Produktivumgebung, einmal mit MTU 1500 und einmal mit MTU 9000 auf derselben Strecke. Die CPU-Auslastung waehrend des Transfers laesst sich parallel mit mpstat 1 beobachten, um die erwartete Reduktion der Interrupt-Last sichtbar zu machen.

Bei MySQL-Replikation zeigt sich der Effekt von Jumbo Frames besonders deutlich in Szenarien mit grossen Binlog-Events, etwa nach Bulk-Updates im Rahmen einer Magento-Preisaktualisierung oder eines Katalog-Imports. Der Replikations-Thread auf dem Slave verarbeitet dann weniger, aber groessere Netzwerkpakete, was die Zeit bis zur vollstaendigen Synchronisation (Replication Lag) messbar verkuerzen kann. Wichtig ist dabei, den Vergleich immer unter identischen Lastbedingungen durchzufuehren, da die Werte sonst durch andere Faktoren wie Festplatten-I/O verzerrt werden.

Fuer Backup-Transfers per rsync oder scp zwischen Applikationsserver und einem dedizierten Backup-Host zeigt sich der Effekt von Jumbo Frames am deutlichsten bei sehr grossen Einzeldateien, etwa Datenbank-Dumps im zweistelligen Gigabyte-Bereich oder vollstaendigen Media-Archiven. Bei vielen kleinen Dateien, wie es bei einer Magento-Medienbibliothek mit tausenden einzelnen Produktbildern der Fall sein kann, dominiert dagegen oft der Overhead durch Dateisystem-Metadaten und einzelne Verbindungsaufbauten staerker als der reine Netzwerk-Overhead, sodass der gemessene Gewinn geringer ausfaellt als bei einem einzelnen grossen Dump.

8. Monitoring mit ethtool und Interface-Statistiken

Nach der Umstellung auf Jumbo Frames lohnt sich eine kontinuierliche Beobachtung der Interface-Statistiken, um Fragmentierung oder Paketverluste fruehzeitig zu erkennen. ethtool -S eth1 liefert treiberspezifische Zaehler wie verworfene Pakete, Fehler bei der Ring-Buffer-Verarbeitung und Ueberlaufzaehler, die bei einer fehlerhaften Jumbo-Frame-Konfiguration typischerweise ansteigen. Ein plötzlicher Anstieg von rx_dropped oder tx_errors nach der MTU-Umstellung deutet fast immer auf ein inkonsistentes Geraet im Pfad hin.

Ergaenzend liefert /proc/net/dev einen schnellen Ueberblick ueber Fehler- und Drop-Zaehler pro Interface, waehrend netstat -s auf Protokollebene zeigt, ob IP-Fragmentierung tatsaechlich stattfindet. Steigt der Zaehler fuer IPReasmFails nach der Umstellung an, ist das ein klares Signal, dass irgendwo im Pfad Pakete fragmentiert und nicht sauber wieder zusammengesetzt werden koennen. In diesem Fall sollte die MTU so lange schrittweise reduziert werden, bis der Fehlerzaehler wieder auf null faellt, bevor erneut auf 9000 Byte erhoeht wird.

Neben Fragmentierungszaehlern lohnt sich auch ein Blick auf die Ring-Buffer-Groesse der Netzwerkkarte, die sich mit ethtool -g eth1 auslesen laesst. Bei hoher Paketrate und aktivierten Jumbo Frames kann ein zu kleiner Ring-Buffer dazu fuehren, dass Pakete verworfen werden, bevor der Kernel sie ueberhaupt verarbeiten kann. In diesem Fall hilft eine Vergroesserung des Buffers mit ethtool -G eth1 rx 4096 tx 4096, sofern die Netzwerkkarte diese Werte unterstuetzt, um Verluste unter Lastspitzen zu vermeiden.

9. MTU 1500 vs. MTU 9000 im direkten Vergleich

Die Entscheidung fuer oder gegen Jumbo Frames haengt stark vom konkreten Workload und der Netzwerktopologie ab. Die folgende Tabelle fasst die wichtigsten Unterschiede fuer typische Magento-Hosting-Szenarien zusammen.

Die Tabelle zeigt: Jumbo Frames sind kein Allheilmittel, sondern eine gezielte Optimierung fuer selbst kontrollierte, interne Netzsegmente mit hohem, sequenziellem Datendurchsatz. Ausserhalb dieser Bedingungen ueberwiegt das Risiko stiller Fehlkonfiguration den moeglichen Performance-Gewinn deutlich.

Fuer die konkrete Entscheidung im eigenen Setup lohnt sich eine kurze Bestandsaufnahme: Wie viele Server tauschen regelmaessig grosse Datenmengen ueber ein selbst kontrolliertes Netzsegment aus, und wie hoch ist die aktuelle CPU-Last durch Netzwerk-Interrupts unter Spitzenlast. Erst wenn beide Werte ein klares Bild ergeben, rechtfertigt sich der zusaetzliche Konfigurationsaufwand von Jumbo Frames gegenueber der einfacheren Standardkonfiguration mit MTU 1500.

Fuer den taeglichen Betrieb bedeutet das: Jumbo Frames gehoeren nicht in die Standardkonfiguration jedes Servers, sondern in eine bewusst getroffene Entscheidung fuer klar abgegrenzte interne Netzsegmente mit hohem Datenaufkommen. Wer diese Abgrenzung sauber dokumentiert und ueber Configuration Management durchsetzt, profitiert dauerhaft von der reduzierten CPU-Last, ohne die Stabilitaet der oeffentlichen Web-Anbindung zu gefaehrden.

10. Zusammenfassung

Jumbo Frames unter Linux reduzieren den relativen Header-Overhead pro uebertragenem Megabyte, indem die MTU von 1500 auf bis zu 9000 Byte erhoeht wird. Der Nutzen entsteht vor allem bei grossen, sequenziellen Datenstroemen innerhalb selbst kontrollierter interner Netze: MySQL-Replikation, Backup-Transfers und der Datenaustausch mit Suchindex-Clustern profitieren am staerksten. Fuer oeffentlichen Web-Traffic sind Jumbo Frames weder relevant noch konfigurierbar, weil die MTU dort vom gesamten Internet-Pfad bestimmt wird.

Die groesste Gefahr liegt in inkonsistenter Konfiguration: Wird die MTU nur auf einem Teil der beteiligten Geraete erhoeht, drohen stiller Paketverlust und schwer diagnostizierbare Verbindungsabbrueche. ping -M do -s, tracepath und ethtool -S sind die zentralen Werkzeuge, um vor und nach der Umstellung die Ende-zu-Ende-Konsistenz zu verifizieren. Wer Jumbo Frames ausschliesslich in selbst kontrollierten internen Segmenten aktiviert und den Effekt mit realistischen Workloads misst, gewinnt spuerbare CPU-Entlastung ohne unkalkulierbares Risiko.

11. FAQ: Jumbo Frames unter Linux