Linux-Kernel-Parameter mit sysctl anpassen

1. Was sysctl wirklich steuert

sysctl ist die Schnittstelle, über die sich hunderte Kernel-Parameter zur Laufzeit lesen und verändern lassen, ohne den Kernel neu zu kompilieren oder das System neu zu starten. Technisch ist sysctl nur ein Werkzeug über der eigentlichen Schnittstelle: dem virtuellen Dateisystem unter /proc/sys. Jeder Parameter dort ist eine Datei, deren Inhalt gelesen oder überschrieben werden kann, und sysctl ist lediglich ein komfortables Kommandozeilen-Werkzeug für genau diese Dateien.

Die Parameter sind in Namespaces wie net, vm, fs und kernel organisiert, die sich direkt in Verzeichnispfaden unter /proc/sys widerspiegeln. So entspricht net.core.somaxconn exakt der Datei /proc/sys/net/core/somaxconn, die Punkte im sysctl-Namen werden zu Schrägstrichen im Pfad. Dieses Wissen ist keine akademische Fußnote, sondern hilft beim Debuggen: Wenn ein Parameter über sysctl nicht wie erwartet reagiert, lohnt sich der direkte Blick in die entsprechende proc-Datei, um zu sehen, was der Kernel tatsächlich verwendet.

2. Laufzeit-Änderungen versus dauerhafte Konfiguration

Der Befehl sysctl -w net.core.somaxconn=4096 ändert den Wert sofort im laufenden Kernel, doch diese Änderung existiert ausschließlich im Arbeitsspeicher. Nach einem Neustart, einem Kernel-Crash oder auch nur einem geplanten Reboot für ein Kernel-Update ist der Parameter wieder auf seinem Standardwert. Genau dieser Unterschied zwischen flüchtiger und dauerhafter Konfiguration ist die häufigste Quelle für das Phänomen, dass ein Tuning nach einem Wartungsfenster plötzlich wirkungslos scheint.

Für dauerhafte Wirkung muss der Parameter in einer Datei unter /etc/sysctl.d/ stehen. Beim Booten liest systemd-sysctl alle passenden Dateien und wendet sie in einer definierten Reihenfolge an, sodass die Einstellung jeden Neustart übersteht. Wer sysctl -w für einen produktiven Test nutzt, sollte den Wert danach immer in eine Konfigurationsdatei übertragen, sobald sich die Einstellung bewährt hat, sonst verpufft die Arbeit beim nächsten Neustart spurlos.

#!/usr/bin/env bash
# Runtime-only change: lost on the next reboot
sudo sysctl -w net.core.somaxconn=4096

# Verify the current runtime value
sysctl net.core.somaxconn

# Same value, read directly from the proc filesystem
cat /proc/sys/net/core/somaxconn

3. Verbindungs-Backlog: die Warteschlange für neue Verbindungen

Für einen stark ausgelasteten Webserver hinter nginx oder php-fpm sind Backlog-Parameter oft die ersten, die an Grenzen stoßen. net.core.somaxconn begrenzt, wie viele bereits vollständig aufgebaute Verbindungen maximal in der Warteschlange auf accept() durch die Anwendung warten dürfen. Der historische Standardwert von 128 stammt aus einer Zeit deutlich geringerer Verbindungsraten und ist auf einem modernen Produktivsystem mit tausenden gleichzeitigen Requests häufig zu niedrig, was zu verworfenen Verbindungen genau in Lastspitzen führt.

Ergänzend begrenzt net.ipv4.tcp_max_syn_backlog die Anzahl halb offener Verbindungen, die noch auf den finalen Handshake-Schritt warten, bevor SYN-Cookies als Schutzmechanismus greifen. Wichtig ist: Der Wert von somaxconn allein reicht nicht, die Anwendung selbst muss beim Aufruf von listen() einen mindestens ebenso großen Backlog anfordern, sonst limitiert der kleinere der beiden Werte. Bei nginx steuert die Direktive backlog im listen-Block genau diesen anwendungsseitigen Wert, der zum Kernel-Parameter passen muss.

# /etc/sysctl.d/99-webserver.conf
# Applied at boot and on demand via sysctl --system

# Increase the accept queue for a busy web server behind nginx/php-fpm
net.core.somaxconn = 4096

# Allow more half-open connections to queue before SYN cookies kick in
net.ipv4.tcp_max_syn_backlog = 8192

# Raise the system-wide file descriptor ceiling
fs.file-max = 2097152

# Prefer page cache over swapping anonymous pages on a web/app server
vm.swappiness = 10

# Reuse TIME_WAIT sockets faster under high connection churn
net.ipv4.tcp_fin_timeout = 15

4. Datei-Limits: fs.file-max und der Zusammenhang mit ulimit

fs.file-max definiert die systemweite Obergrenze offener Dateideskriptoren über alle Prozesse hinweg, nicht pro Prozess. Jede geöffnete Datei, jeder Socket und jede Named Pipe zählt gegen dieses Limit. Auf einem Webserver mit vielen gleichzeitigen Verbindungen, Log-Dateien und geöffneten Datenbank-Sockets kann der Kernel-Standardwert, der oft an die verfügbare RAM-Größe gekoppelt berechnet wird, überraschend knapp werden, besonders bei Systemen mit wenig RAM aber vielen kurzlebigen Verbindungen.

Wichtig ist die Abgrenzung zu ulimit: fs.file-max setzt die systemweite Obergrenze, während ulimit -n beziehungsweise die LimitNOFILE-Direktive in einer systemd-Unit das Limit pro Prozess festlegt. Ein hoher fs.file-max-Wert nützt nichts, wenn der php-fpm- oder nginx-Prozess durch eine niedrige LimitNOFILE trotzdem blockiert wird. Beide Ebenen müssen zueinander passen, sonst scheitert die Anwendung mit Too many open files, obwohl das Systemlimit noch deutlich Luft hätte.

#!/usr/bin/env bash
set -euo pipefail

# Load every *.conf file under /etc/sysctl.d/ in lexical order
sudo sysctl --system

# Show exactly which files were read and in what order
sudo sysctl --system 2>&1 | grep -E '^\* '

# Confirm a specific parameter matches the intended value
expected=4096
actual=$(sysctl -n net.core.somaxconn)
[[ "$actual" -eq "$expected" ]] && echo "OK: somaxconn=$actual" || echo "MISMATCH: got $actual"

5. vm.swappiness: Speicherverhalten unter Last

vm.swappiness gehört ebenfalls zu den Parametern, die auf einem Webserver häufig unreflektiert vom Standardwert 60 belassen werden, obwohl dieser Wert ein Kompromiss für Desktop-Systeme ist. Der Parameter steuert die relative Gewichtung zwischen dem Freigeben von Page-Cache und dem Auslagern anonymer Speicherseiten, wenn der Kernel Platz im Arbeitsspeicher schaffen muss. Für einen Webserver, dessen Performance stark vom Page-Cache für Assets, Templates und OPcache-Daten abhängt, bevorzugt ein niedriger Wert zwischen 10 und 20 das Zurückhalten dieses Caches gegenüber dem Auslagern von Anwendungsspeicher.

Ein zu niedriger Wert ist allerdings kein Freifahrtschein: Bei echtem Speicherdruck lagert der Kernel trotzdem aus, ein Wert von 0 bedeutet lediglich, dass Page-Cache bis zum äußersten Notfall bevorzugt wird, nicht dass Swap niemals genutzt wird. Wer vm.swappiness anpasst, sollte parallel mit vmstat 1 die Spalten si und so beobachten, um zu sehen, ob die Änderung tatsächlich weniger Auslagerung bewirkt oder ob der eigentliche Engpass schlicht zu wenig RAM ist, das kein Kernel-Parameter kompensieren kann.

6. /etc/sysctl.d richtig strukturieren

Statt alle Parameter in der monolithischen /etc/sysctl.conf zu sammeln, empfiehlt sich eine Aufteilung in mehrere thematische Dateien unter /etc/sysctl.d/, etwa 99-webserver.conf für Netzwerk- und Datei-Limits sowie 99-security.conf für sicherheitsrelevante Parameter. Dateien werden in lexikalischer Reihenfolge nach ihrem Namen geladen, weshalb eine zweistellige Nummer am Anfang des Dateinamens die Reihenfolge explizit festlegt. Kollidieren zwei Dateien im selben Parameter, gewinnt die zuletzt geladene Datei, was bei unklarer Namensgebung zu schwer nachvollziehbaren Überschreibungen führen kann.

Distributionen und Pakete legen eigene Dateien unter /usr/lib/sysctl.d/ ab, die als Vendor-Defaults gelten und von administrativen Änderungen unter /etc/sysctl.d/ überschrieben werden dürfen. Eigene Konfigurationsdateien gehören ausschließlich nach /etc/sysctl.d/, niemals in die Vendor-Verzeichnisse, da diese bei einem Paket-Update kommentarlos überschrieben werden. Konsequente Dateinamen mit Präfix, etwa 99-mironsoft-webserver.conf, machen zudem sofort erkennbar, welche Datei aus welchem Deployment stammt.

# ansible: apply and persist sysctl values across a fleet of web servers
- name: Tune kernel parameters for busy web servers
  ansible.posix.sysctl:
    name: "{{ item.name }}"
    value: "{{ item.value }}"
    sysctl_file: /etc/sysctl.d/99-webserver.conf
    reload: true
  loop:
    - { name: net.core.somaxconn, value: "4096" }
    - { name: net.ipv4.tcp_max_syn_backlog, value: "8192" }
    - { name: fs.file-max, value: "2097152" }
    - { name: vm.swappiness, value: "10" }

7. Änderungen validieren und live beobachten

Nach dem Anlegen einer Konfigurationsdatei bestätigt sysctl --system, welche Dateien in welcher Reihenfolge geladen wurden, und meldet Syntaxfehler sofort statt sie stillschweigend zu ignorieren. Der ältere Befehl sysctl -p lädt nur die klassische /etc/sysctl.conf und übersieht dabei die Dateien unter /etc/sysctl.d/, weshalb sysctl --system auf aktuellen Systemen die zuverlässigere Wahl ist. Mit sysctl -a lässt sich der komplette aktuelle Parametersatz ausgeben, gefiltert mit grep auf den relevanten Namespace, etwa sysctl -a | grep ^net.core.

Für Monitoring in der Produktion lohnt sich ein regelmäßiger Abgleich zwischen dem gewünschten Soll-Zustand und dem tatsächlich aktiven Wert, denn ein manueller sysctl -w-Eingriff eines Kollegen oder ein fehlerhaftes Deployment kann den Zustand unbemerkt driften lassen. Ein einfaches Monitoring-Skript, das die kritischen Parameter zyklisch gegen die erwarteten Werte prüft, deckt solche Abweichungen auf, bevor sie in einer Lastspitze zum Problem werden.

{
  "check": "kernel_parameter_drift",
  "interval_seconds": 300,
  "parameters": [
    { "key": "net.core.somaxconn", "expected": "4096" },
    { "key": "fs.file-max", "expected": "2097152" },
    { "key": "vm.swappiness", "expected": "10" }
  ],
  "action": {
    "on_drift": "log",
    "on_missing_file": "page_oncall"
  }
}

8. Das Risiko blind kopierter Tuning-Guides

Viele Tuning-Guides im Netz stammen aus einer anderen Kernel-Version, einem anderen Workload-Profil oder schlicht einer anderen Ära der Hardware, und ein unreflektiertes Kopieren dieser Werte kann mehr schaden als nützen. Ein klassisches Beispiel ist net.ipv4.tcp_syncookies = 0, das in manchen alten Performance-Guides empfohlen wird, um vermeintlich Overhead zu sparen. Tatsächlich deaktiviert dieser Wert den Schutz gegen SYN-Flood-Angriffe komplett und öffnet ein reales Sicherheitsrisiko für einen minimalen, kaum messbaren Geschwindigkeitsgewinn.

Ähnlich riskant ist das Kopieren von net.ipv4.ip_forward = 1 aus einem Docker- oder Router-Tuning-Guide auf einen normalen Webserver, wodurch das System versehentlich zum IP-Router wird und Pakete zwischen Netzwerkschnittstellen weiterleitet, was auf einem öffentlich erreichbaren Server ein Sicherheitsproblem darstellt. Jeder Parameter in einer Konfigurationsdatei sollte mit einem Kommentar versehen sein, der erklärt, warum genau dieser Wert gewählt wurde und welches konkrete Problem er löst. Ohne diese Begründung wird eine sysctl-Datei nach einigen Jahren zu einer Blackbox, die niemand mehr anzufassen wagt, aus Angst, etwas Wichtiges zu zerstören.

9. sysctl-Parameter im direkten Vergleich

Die folgende Tabelle stellt typische Fehlkonfigurationen den empfohlenen Einstellungen für einen stark ausgelasteten Webserver gegenüber. Sie ersetzt keine individuelle Analyse der eigenen Workload, zeigt aber die Richtung, in die eine bewusste Konfiguration im Vergleich zu unreflektiert übernommenen Standardwerten oder blind kopierten Guides gehen sollte.

In der Praxis liefert eine kurze Checkliste vor jedem Tuning die meiste Sicherheit: Zweck des Parameters verstehen, Wert dokumentieren, Änderung zunächst mit sysctl -w testen und erst nach Bestätigung dauerhaft in /etc/sysctl.d/ übernehmen, und Monitoring auf die tatsächlich aktiven Werte statt auf die reine Existenz einer Konfigurationsdatei ausrichten.

10. Zusammenfassung

sysctl ist das zentrale Werkzeug, um Kernel-Verhalten auf Linux-Servern ohne Neukompilierung zu steuern, doch der Unterschied zwischen einer flüchtigen Laufzeit-Änderung mit sysctl -w und einer dauerhaften Konfiguration unter /etc/sysctl.d/ entscheidet darüber, ob ein Tuning einen Neustart übersteht. Für stark ausgelastete Webserver sind Backlog-Parameter wie net.core.somaxconn und net.ipv4.tcp_max_syn_backlog, die systemweite Datei-Obergrenze fs.file-max im Zusammenspiel mit ulimit sowie vm.swappiness für das Speicherverhalten unter Last die Parameter mit dem größten praktischen Effekt.

Der größte Risikofaktor ist nicht ein falsch gesetzter Einzelwert, sondern das unreflektierte Kopieren fremder Tuning-Guides ohne zu verstehen, welches Problem ein Parameter tatsächlich löst und welche Nebenwirkungen er hat, wie das Beispiel tcp_syncookies = 0 zeigt. Wer jeden Parameter dokumentiert, Änderungen zunächst zur Laufzeit testet und erst danach dauerhaft in eine klar benannte Datei unter /etc/sysctl.d/ überträgt, baut eine nachvollziehbare und wartbare Kernel-Konfiguration auf, statt eine Blackbox, an die sich niemand mehr herantraut.

11. FAQ: Linux-Kernel-Parameter mit sysctl