Linux sysctl ist die primäre Schnittstelle zum Lesen und Ändern von Kernel-Parametern zur Laufzeit, ohne das System neu zu starten. Ob Sie einen hochfrequentierten Webserver, einen Datenbankhost oder containerisierte Workloads betreiben — das Optimieren des Kernels mit sysctl kann den Durchsatz erheblich verbessern, die Latenz reduzieren und Ressourcenerschöpfung verhindern. In dieser Anleitung erfahren Sie, welche Parameter am wichtigsten sind, wie Sie sie sicher anwenden und wie Sie sie über /etc/sysctl.conf und Drop-in-Konfigurationsdateien unter /etc/sysctl.d/ dauerhaft machen.

Voraussetzungen

  • Ein Linux-System mit Kernel 4.x oder neuer (Ubuntu 20.04+, Debian 11+, RHEL 8+ oder vergleichbar)
  • sudo- oder Root-Zugriff
  • Grundkenntnisse der Kommandozeile und eines Texteditors (nano, vim oder vi)
  • Verständnis der Workload des Servers (Webdienste, Datenbanken, Allzweck)

Die sysctl-Schnittstelle verstehen

Der Befehl sysctl ist eine dünne Schicht über dem Pseudo-Dateisystem /proc/sys/. Jeder optimierbare Parameter besitzt eine entsprechende Datei in diesem Pfad. Der Parameter net.ipv4.tcp_fin_timeout entspricht beispielsweise /proc/sys/net/ipv4/tcp_fin_timeout. Sie können ihn direkt mit cat oder über sysctl lesen:

# Beide Befehle liefern dasselbe Ergebnis
sysctl net.ipv4.tcp_fin_timeout
cat /proc/sys/net/ipv4/tcp_fin_timeout

Das Schreiben in diese Dateien ist gleichbedeutend mit sysctl -w, aber Änderungen auf beiden Wegen sind temporär — sie gehen beim Neustart verloren. Der empfohlene Arbeitsablauf lautet: zuerst mit -w testen, dann in einer Konfigurationsdatei speichern, sobald Sie zufrieden sind.

Alle Tunables auf einmal anzeigen:

sysctl -a

Nach Namespace filtern:

sysctl -a | grep net.ipv4.tcp

Speicherverwaltungsparameter

vm.swappiness

vm.swappiness steuert, wie bereitwillig der Kernel Speicherseiten vom RAM in den Swap-Speicher verschiebt. Die Skala reicht von 0 (Swapping so weit wie möglich vermeiden) bis 200 (aggressives Swapping). Der Kernel-Standard ist 60.

Für Anwendungsserver und Datenbanken, die Daten im RAM halten müssen:

sudo sysctl -w vm.swappiness=10

Für Desktop-Systeme, bei denen Reaktionsfähigkeit wichtiger ist als warme Caches, können 60 oder sogar höhere Werte geeignet sein. Bei Systemen ohne Swap verhindert der Wert 0 jegliche Swap-Aktivität.

vm.dirty_ratio und vm.dirty_background_ratio

Diese Parameter steuern, wie viel schmutzigen (nicht geschriebenen) Speicher das System toleriert, bevor ein Flush auf die Festplatte erzwungen wird.

  • vm.dirty_background_ratio (Standard 10) — Prozentsatz des Gesamtspeichers, bei dem das Hintergrund-Write-Back beginnt
  • vm.dirty_ratio (Standard 20) — Prozentsatz, bei dem Prozesse blockiert werden, bis schmutzige Seiten geschrieben sind

Für Server mit schnellen SSDs oder hohen Schreib-Workloads reduzieren niedrigere Werte das Risiko großer Schreib-Stalls:

sudo sysctl -w vm.dirty_background_ratio=5
sudo sysctl -w vm.dirty_ratio=10

vm.vfs_cache_pressure

Dieser Parameter steuert, wie aggressiv der Kernel Speicher zurückfordert, der für das Caching von Verzeichnis- und Inode-Objekten verwendet wird. Der Standard ist 100. Ein niedrigerer Wert (z.B. 50) lässt den Kernel Dateisystem-Metadaten länger im Cache halten, was Workloads mit vielen kleinen Dateien zugute kommt:

sudo sysctl -w vm.vfs_cache_pressure=50

Netzwerk-Stack-Optimierung mit net.core und net.ipv4

net.core.somaxconn

net.core.somaxconn legt die maximale Länge der Listen-Warteschlange für das Akzeptieren neuer TCP-Verbindungen fest. Der Kernel-Standard ist 128, was für jeden webbasierten Dienst viel zu niedrig ist. Nginx, Apache und Node.js profitieren alle von einem deutlich größeren Wert:

sudo sysctl -w net.core.somaxconn=65535

Ihre Anwendung muss auch listen() mit einem großen Backlog aufrufen. Setzen Sie für Nginx listen 80 backlog=65535; im Server-Block.

net.core.netdev_max_backlog

Dies steuert, wie viele Pakete die Netzwerkkarte einreihen kann, bevor der Kernel sie verwirft. Unter hochbandbreitigen Lasten kann der Standard von 1000 zu Paketverlust führen:

sudo sysctl -w net.core.netdev_max_backlog=5000

TCP-Puffergrößen

Der Kernel verwendet Pro-Socket-Empfangs- und Sendepuffer, um In-Flight-Daten zu halten. Größere Puffer verbessern den Durchsatz auf Verbindungen mit hoher Latenz (Long Fat Networks):

# Minimaler, Standard-, Maximal-Empfangspuffer (Bytes)
sudo sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"

# Minimaler, Standard-, Maximal-Sendepuffer (Bytes)
sudo sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"

# Globales Maximum für Socket-Puffer
sudo sysctl -w net.core.rmem_max=16777216
sudo sysctl -w net.core.wmem_max=16777216

TIME_WAIT und Verbindungswiederverwendung

Hochfrequentierte Server erstellen Tausende kurzlebiger Verbindungen. Ohne Optimierung verweilen Sockets bis zu zwei Minuten im TIME_WAIT-Zustand und erschöpfen die ephemeren Ports:

# TIME_WAIT-Sockets für neue ausgehende Verbindungen wiederverwenden
sudo sysctl -w net.ipv4.tcp_tw_reuse=1

# TIME_WAIT-Dauer verkürzen (Standard 60 Sekunden)
sudo sysctl -w net.ipv4.tcp_fin_timeout=30

# Lokalen Portbereich für ausgehende Verbindungen erweitern
sudo sysctl -w net.ipv4.ip_local_port_range="1024 65535"

SYN-Flood-Schutz

SYN-Cookies aktivieren, um vor SYN-Flood-Angriffen zu schützen, ohne legitime Verbindungen zu verwerfen:

sudo sysctl -w net.ipv4.tcp_syncookies=1
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=2048

Dateideskriptor- und Prozesslimits

Hochgradig nebenläufige Server (Webserver, Message Broker, Monitoring-Agenten) öffnen Tausende von Dateideskriptoren gleichzeitig. Das systemweite Kernel-Limit wird durch fs.file-max gesteuert:

# Aktuelles systemweites Maximum anzeigen
sysctl fs.file-max

# Auf 2 Millionen für stark ausgelastete Server erhöhen
sudo sysctl -w fs.file-max=2000000

Beachten Sie, dass fs.file-max eine Kernel-Obergrenze ist. Sie müssen auch die Limits pro Prozess über /etc/security/limits.conf oder die systemd-Unit LimitNOFILE erhöhen, damit einzelne Prozesse den neuen Spielraum nutzen können.

Einstellungen dauerhaft machen: sysctl.conf vs. Drop-in-Dateien

Der klassische Ansatz: /etc/sysctl.conf

Parameter direkt in /etc/sysctl.conf hinzufügen:

# Speicher-Optimierung
vm.swappiness = 10
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
vm.vfs_cache_pressure = 50

# Netzwerk-Optimierung
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048

# Dateideskriptor-Limit
fs.file-max = 2000000

Ohne Neustart anwenden:

sudo sysctl -p

Der moderne Ansatz: /etc/sysctl.d/ Drop-in-Dateien

Drop-in-Dateien unter /etc/sysctl.d/ sind der bevorzugte Ansatz auf systemd-basierten Distributionen. Sie ermöglichen es Paketen, Konfigurationsmanagement-Tools (Ansible, Puppet, Chef) und benutzerdefinierten Skripten, jeweils eigene Parameter zu verwalten, ohne eine gemeinsame Datei zu bearbeiten.

Eine dedizierte Datei erstellen:

sudo nano /etc/sysctl.d/99-webserver-tuning.conf

Parameter im gleichen schlüssel = wert-Format hinzufügen. Alle Drop-in-Dateien und /etc/sysctl.conf neu laden mit:

sudo sysctl --system

Dateien werden in lexikografischer Reihenfolge verarbeitet. Das Präfix 99- stellt sicher, dass Ihre Datei zuletzt geladen wird und alle widersprüchlichen Standardwerte von OS-Paketen überschreibt.

Standard vs. empfohlene Parameter: Vergleichstabelle

ParameterKernel-StandardEmpfohlen (Webserver)Hinweise
vm.swappiness6010Anwendungsdaten im RAM halten
vm.dirty_background_ratio105Schmutzige Seiten früher flushen
vm.dirty_ratio2010Risiko von Schreib-Stalls reduzieren
vm.vfs_cache_pressure10050Verzeichnis-Metadaten länger cachen
net.core.somaxconn12865535Hohe Verbindungsparallelität unterstützen
net.core.netdev_max_backlog10005000Paketverlust unter Last vermeiden
net.ipv4.tcp_fin_timeout6030Sockets schneller freigeben
net.ipv4.tcp_tw_reuse01TIME_WAIT-Sockets wiederverwenden
net.ipv4.ip_local_port_range32768–609991024–65535Mehr ephemere Ports
fs.file-max~1000002000000Hohe Anzahl offener Dateien unterstützen

Praxisbeispiel

Sie betreiben einen produktiven Nginx-Server, der 5.000 gleichzeitige HTTP-Verbindungen verarbeitet. Benutzer sehen zeitweise 502 Bad Gateway-Fehler und Verbindungs-Timeouts zu Spitzenzeiten. Sie führen ss -s aus und sehen Tausende von Sockets im TIME_WAIT-Zustand, und dmesg zeigt TCP: request_sock_TCP: Possible SYN flooding on port 443. Der Server hat 16 GB RAM und nutzt kaum Swap, doch free -h zeigt eine niedrige Buffer/Cache-Nutzung.

Hier ist die Optimierungsabfolge, die Sie anwenden:

# Schritt 1: Diagnose
ss -s
sysctl net.core.somaxconn net.ipv4.tcp_fin_timeout fs.file-max

# Schritt 2: Korrekturen zur Laufzeit anwenden
sudo sysctl -w net.core.somaxconn=65535
sudo sysctl -w net.ipv4.tcp_tw_reuse=1
sudo sysctl -w net.ipv4.tcp_fin_timeout=30
sudo sysctl -w net.ipv4.ip_local_port_range="1024 65535"
sudo sysctl -w net.ipv4.tcp_syncookies=1
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=2048
sudo sysctl -w vm.swappiness=10
sudo sysctl -w fs.file-max=2000000

# Schritt 3: 15 Minuten überwachen
watch -n 5 ss -s

# Schritt 4: Bei Verbesserung Einstellungen dauerhaft speichern
sudo tee /etc/sysctl.d/99-webserver-tuning.conf <<'EOF'
net.core.somaxconn = 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048
vm.swappiness = 10
fs.file-max = 2000000
EOF

sudo sysctl --system

Die TIME_WAIT-Anzahl sinkt innerhalb von Minuten von mehreren Tausend auf wenige Hundert, und die 502-Fehler hören auf.

Fallstricke und Sonderfälle

Änderungen werden nicht von laufenden Prozessen übernommen. Wenn Sie fs.file-max erhöhen, arbeiten bereits laufende Nginx-Worker weiterhin unter dem alten Pro-Prozess-Limit. Sie müssen auch /etc/security/limits.conf aktualisieren und den Dienst neu starten oder LimitNOFILE in der systemd-Unit-Datei setzen.

tcp_tw_reuse gilt nur für ausgehende Verbindungen. Es ermöglicht dem lokalen Stack, einen TIME_WAIT-Socket als Quelle einer neuen ausgehenden Verbindung wiederzuverwenden. Es betrifft keine eingehenden Verbindungen von Clients. Verwechseln Sie es nicht mit tcp_tw_recycle, das in Kernel 4.12 entfernt wurde und hinter NAT zu Verbindungsfehlern geführt hatte.

net.core.somaxconn ist eine Obergrenze, kein Mindestwert. Wenn Ihre Anwendung listen() mit einem kleineren Backlog aufruft, verwendet der Kernel den niedrigeren der beiden Werte. Optimieren Sie sowohl den Kernel-Parameter als auch die Anwendungskonfiguration.

Container erben den Host-Kernel-Namespace. Sysctl-Parameter, die in /etc/sysctl.d/ auf dem Host gesetzt werden, gelten für alle Container. Einige Parameter können per Netzwerk-Namespace mit docker run --sysctl oder Kubernetes-Pod-Sicherheitskontexten gesetzt werden, aber die meisten erfordern Host-Level-Zugriff.

Tests mit unrealistischen Workloads sind riskant. Führen Sie Benchmarks immer mit Datenverkehr durch, der die Produktion widerspiegelt. Ein Parameter, der den Durchsatz in einem Lab-Test verbessert, kann die Latenz in der Produktion verschlechtern, wenn sich die Workload-Eigenschaften unterscheiden.

Fehlerbehebung

Zugriff verweigert beim Schreiben eines Parameters: Einige Parameter sind schreibgeschützt (in /proc/sys/ als Modus 444 markiert) und können zur Laufzeit nicht geändert werden. Andere erfordern eine bestimmte Kernel-Build-Option. Prüfen Sie dmesg auf Fehlermeldungen nach einem Schreibversuch.

Einstellung überlebt keinen Neustart: Überprüfen Sie, ob die Datei unter /etc/sysctl.d/ mit der Erweiterung .conf liegt und keine Syntaxfehler enthält. Führen Sie sudo sysctl --system aus und prüfen Sie die Ausgabe auf “Applying /etc/sysctl.d/99-custom.conf”, um zu bestätigen, dass sie geladen wird.

Fehler “Parameter nicht gefunden” (sysctl: cannot stat /proc/sys/...): Der Parameter erfordert ein Kernel-Modul, das nicht geladen ist. Laden Sie das Modul zuerst (z.B. modprobe nf_conntrack) und versuchen Sie es erneut.

Unerwartet niedrige Werte nach dem Anwenden der Einstellungen: Eine später geladene Konfigurationsdatei überschreibt Ihre Einstellungen. Prüfen Sie die Ladereihenfolge in der sysctl --system-Ausgabe und benennen Sie Ihre Datei mit einem höheren numerischen Präfix um (z.B. 99- statt 10-).

Zusammenfassung

  • sysctl liest und schreibt Kernel-Parameter, die über /proc/sys/ bereitgestellt werden, zur Laufzeit ohne Neustart
  • Verwenden Sie sysctl -w für temporäre Tests, dann speichern Sie funktionierende Werte in /etc/sysctl.d/99-custom.conf
  • Verwenden Sie sudo sysctl --system, um alle Konfigurationsdateien neu zu laden; sudo sysctl -p lädt nur /etc/sysctl.conf neu
  • vm.swappiness=10 hält Anwendungsdaten auf Servern mit ausreichend Arbeitsspeicher im RAM
  • net.core.somaxconn=65535 und net.ipv4.tcp_tw_reuse=1 sind die wirkungsvollsten Änderungen für Webserver-Parallelität
  • fs.file-max setzt die Kernel-Obergrenze für offene Dateien — Sie müssen auch Pro-Prozess-Limits in der Anwendung oder systemd-Unit erhöhen
  • Drop-in-Dateien unter /etc/sysctl.d/ sind dem direkten Bearbeiten von /etc/sysctl.conf vorzuziehen
  • Wenden Sie Änderungen immer zuerst zur Laufzeit an, überwachen Sie unter Last, und speichern Sie dauerhaft nur das, was sich bewährt hat

Verwandte Artikel