Linux Performance Tuning beginnt beim Kernel — sysctl-Parameter, Scheduler-Wahl und Speicherarchitektur bestimmen, ob ein Server unter Last liefert oder kollabiert.
Kernel-Parameter (sysctl) — Die Einstellungen, die wirklich zählen
Die Datei /etc/sysctl.conf (bzw. Dateien unter /etc/sysctl.d/) ist der Schlüssel zur Kernel-Konfiguration im laufenden Betrieb. Während die meisten Linux-Distributionen mit konservativen Standardwerten ausgeliefert werden, die für Desktop-Systeme optimiert sind, erfordern Produktivserver grundlegend andere Einstellungen. Die folgenden Parameter stammen aus der Praxis mit Hochlast-Webservern, Datenbankservern und Container-Hosts — jeder einzelne löst ein konkretes Problem, das unter Last auftritt.
Besonders kritisch ist das Zusammenspiel von Swap-Verhalten und Dirty-Page-Management. Der Linux-Kernel versucht standardmäßig, so viel RAM wie möglich als Festplatten-Cache zu verwenden, und lagert dafür Anwendungsspeicher auf die Swap-Partition aus. Für Desktop-Systeme ist das sinnvoll — für einen Datenbankserver mit 128 GB RAM, der seinen Buffer Pool im Speicher halten muss, ist es katastrophal. Gleichzeitig kann die Dirty-Page-Verwaltung bei hoher Schreiblast zu I/O-Staus führen, bei denen alle Prozesse für Sekunden blockiert werden.
Alle Änderungen werden mit sysctl -p sofort aktiviert. Für permanente Konfiguration legen Sie eine Datei wie /etc/sysctl.d/99-server-tuning.conf an. Prüfen Sie aktuelle Werte jederzeit mit sysctl -a | grep parameter.
vm.swappiness=10— Swap-Aggressivität reduzieren: Der Standardwert von60bedeutet, dass der Kernel relativ früh Anwendungsspeicher auf die Swap-Partition auslagert. Für Server ist das kontraproduktiv: Datenbankprozesse verlieren ihren Buffer Pool. Setzen Sie den Wert auf10für allgemeine Server. Datenbankserver profitieren oft von1.vm.dirty_ratio=10undvm.dirty_background_ratio=5: Diese Parameter steuern, wie viel RAM mit „schmutzigen“ Daten belegt sein darf. Der Standard erlaubt bei 128 GB RAM bis zu 25 GB Dirty Pages — wenn diese dann auf einmal geschrieben werden müssen, entsteht ein I/O-Sturm. Reduzieren Sie auf10/5.net.core.somaxconn=65535undnet.ipv4.tcp_max_syn_backlog=65535: Dersomaxconn-Standard von128begrenzt die Listen-Backlog-Queue. Bei Webservern mit Lastspitzen werden neue Verbindungen schlicht verworfen. Beide Werte auf65535setzen.net.ipv4.tcp_tw_reuse=1— TIME_WAIT-Recycling: Erlaubt die sichere Wiederverwendung von TIME_WAIT-Sockets für ausgehende Verbindungen. Wichtig: Nicht verwechseln mit dem veraltetentcp_tw_recycle, der seit Kernel 4.12 entfernt wurde.net.core.netdev_max_backlog=65535— NIC-Warteschlange: Der Standard von1000reicht für 1-Gbit-Interfaces. Auf Servern mit 10-Gbit- oder 25-Gbit-NICs werden bei Lastspitzen Pakete gedroppt. Prüfen Sie Drops mitcat /proc/net/softnet_stat.fs.file-max=2097152undfs.inotify.max_user_watches=524288: Derfile-max-Parameter begrenzt die Gesamtzahl geöffneter Dateideskriptoren systemweit. Derinotify-Wert begrenzt die Anzahl überwachter Dateien. Ergänzen Sie mitulimit-Einstellungen in/etc/security/limits.conf.kernel.pid_max=4194304— Container-Hosts: Auf Container-Hosts mit Kubernetes kann der Standard von32768erreicht werden. Setzen Sie den Wert auf4194304(Maximum auf 64-Bit-Systemen) und überwachen Sie die aktuelle Nutzung mitls /proc | grep -c '^[0-9]'.
NUMA, Huge Pages & cgroups v2 — Fortgeschrittenes Speicher- und Prozessmanagement
Auf Servern mit mehreren CPU-Sockets wird die Speicherarchitektur zum entscheidenden Performance-Faktor. NUMA (Non-Uniform Memory Access) bedeutet, dass jeder CPU-Socket seinen eigenen lokalen Speicher hat. Ein Zugriff auf den lokalen Speicher dauert ~70 ns, ein Zugriff auf den Speicher des anderen Sockets 100–300 ns. Bei speicherintensiven Workloads wie Datenbanken kann die korrekte NUMA-Konfiguration den Unterschied zwischen 500.000 und 800.000 Queries pro Sekunde ausmachen.
Huge Pages (2 MB oder 1 GB statt der Standard-4-KB-Pages) eliminieren TLB-Misses, die bei großen Speicherbereichen zu messbaren Performance-Einbußen führen. Während Transparent Huge Pages (THP) automatisch arbeiten, verursachen sie bei Datenbanken (PostgreSQL, MongoDB, Redis) Latenzspitzen durch den Defragmentierungs-Thread khugepaged.
Mit cgroups v2 erhalten Administratoren granulare Kontrolle über CPU, Speicher und I/O pro Dienst oder Container. In Kombination mit systemd bieten cgroups v2 eine mächtige Ressourcenverwaltung, die ungeplante Ausfälle durch einzelne Dienste verhindert.
- NUMA-Awareness für Datenbanken: Prüfen Sie die NUMA-Topologie mit
numactl --hardwareund die aktuelle Speicherverteilung mitnumastat. Für Datenbanken binden Sie den Prozess an einen NUMA-Node:numactl --cpunodebind=0 --membind=0 postgres. Überwachen Sie Remote-Zugriffe mitnumastat -c— der Anteil an other_node-Zugriffen sollte unter 10 % liegen. - Huge Pages (2 MB / 1 GB) konfigurieren: Für 8 GB Shared Buffers benötigen Sie 4096 Huge Pages à 2 MB. Setzen Sie
vm.nr_hugepages=4096in/etc/sysctl.conf. PostgreSQL muss mithuge_pages = oninpostgresql.confkonfiguriert werden. Prüfen Sie die Zuweisung mitcat /proc/meminfo | grep HugePages. - THP deaktivieren für Datenbanken: Der Kernel-Thread
khugepagedkann einzelne Prozesse für Millisekunden blockieren. Deaktivieren Sie THP mitecho madvise > /sys/kernel/mm/transparent_hugepage/enabledundecho madvise > /sys/kernel/mm/transparent_hugepage/defrag. - cgroups v2 — Ressourcen-Limits per Dienst: CPU:
cpu.max "200000 100000"= maximal 2 CPU-Kerne. Speicher:memory.maxsetzt die Obergrenze,memory.swap.max=0verhindert Swap-Nutzung. I/O:io.max "8:0 rbps=52428800 wbps=52428800"begrenzt Disk-I/O auf 50 MB/s. - OOM-Killer gezielt steuern: Schützen Sie kritische Dienste mit
echo -1000 > /proc/PID/oom_score_adj. In systemd:OOMScoreAdjust=-900. Setzen Sievm.oom_kill_allocating_task=1. Überwachen Sie OOM-Events mitdmesg | grep -i oom. - I/O-Scheduler-Wahl: Für NVMe-SSDs:
none(kein Scheduling, nativ parallel). Für SATA-SSDs und HDDs mit Datenbank-Workloads:mq-deadline. Für Desktop/interaktive Workloads:bfq. Prüfen Sie den aktuellen Scheduler mitcat /sys/block/sda/queue/scheduler. - CPU-Governor für Server: Der Standard-Governor
schedutilpasst die CPU-Frequenz dynamisch an — für Server mit konstanter Last istperformancedie bessere Wahl. Setzen Sie ihn mitcpupower frequency-set -g performanceoder persistent in/etc/default/cpufrequtils.
Dateisystem & Monitoring — Tuning und Observability
Die Wahl und Konfiguration des Dateisystems hat einen direkten Einfluss auf die I/O-Performance, der häufig unterschätzt wird. Ein XFS-Dateisystem mit korrekten Mount-Optionen kann den doppelten Durchsatz eines falsch konfigurierten ext4 liefern. Gleichzeitig entscheiden die Mount-Optionen darüber, ob jeder Lesezugriff einen zusätzlichen Schreibvorgang (atime-Update) auslöst — ein Detail, das auf einem Mailserver mit Millionen kleiner Dateien den Unterschied zwischen flüssigem Betrieb und I/O-Stillstand ausmachen kann.
Im Bereich Observability haben sich in den letzten Jahren die eBPF-basierten Tools (bpftrace, bcc-tools) als revolutionär erwiesen. Sie ermöglichen Echtzeit-Analyse des Kernel-Verhaltens ohne Overhead und ohne Neustart — von Disk-I/O-Latenz pro Prozess bis hin zu TCP-Retransmissions pro Verbindung.
Für langfristiges Monitoring ist Prometheus mit node_exporter der De-facto-Standard in der Linux-Welt. Die richtigen Metriken und Alerting-Schwellenwerte zu kennen ist jedoch genauso wichtig wie die Installation selbst.
- XFS vs. ext4 vs. ZFS — Einsatzgebiete: XFS ist optimal für große Dateien und parallele I/O (SAP HANA, Videoproduktion, Backup-Volumes). ext4 ist der Allrounder für allgemeine Workloads. ZFS (via OpenZFS) bietet Datenintegrität durch Checksummen, Copy-on-Write-Snapshots und Inline-Kompression. Ideal für NAS-Systeme.
- Mount-Optionen, die den Unterschied machen:
noatimedeaktiviert die Aktualisierung des Zugriffszeitstempels — auf einem Mailserver kann dies die IOPS um 30–50 % reduzieren.discardaktiviert TRIM für SSDs.barrier=0erhöht die Schreib-Performance — aber nur auf RAID-Controllern mit batteriegepuffertem Schreib-Cache. - perf + bpftrace — Live-Kernel-Analyse:
perf topzeigt in Echtzeit, welche Kernel- und Userspace-Funktionen die meiste CPU verbrauchen. bpftrace ermöglicht Einzeiler-Diagnosen:bpftrace -e 'tracepoint:block:block_rq_issue { @[comm] = count(); }'zeigt, welcher Prozess die meisten Disk-I/O-Anfragen stellt. - sar + vmstat + iostat — Die Klassiker richtig lesen:
sar -d 1 10zeigt Disk-Aktivität pro Device.vmstat 1: Die Spaltensiundso(Swap In/Out) müssen null sein.iostat -x 1:await> 10 ms signalisiert langsame Festplatten,%util> 80 % zeigt Gerätesättigung. - Prometheus + node_exporter — Die richtigen Metriken: Wichtige Metriken:
node_cpu_seconds_total,node_memory_MemAvailable_bytes(aussagekräftiger als MemFree),node_disk_io_time_weighted_seconds_total(zuverlässigster Indikator für Disk-Sättigung),node_network_receive_errs_totalundnode_network_transmit_errs_total. - strace für Prozess-Diagnose: Wenn ein Prozess hängt oder langsam ist:
strace -p PID -e trace=open,read,write -Tzeigt alle Datei-Operationen mit Zeitstempel.strace -c -p PIDzeigt eine Zusammenfassung aller Systemaufrufe — ideal für die Identifikation des Engpasses. - Netzwerk-Diagnose auf Kernel-Ebene:
ss -tnpzeigt alle TCP-Verbindungen mit zugehörigen Prozessen.nstat -azeigt Kernel-Netzwerkstatistiken inkl. TCP-Retransmissions.bpftrace -e 'kprobe:tcp_retransmit_skb { @[comm, pid] = count(); }'zeigt, welche Prozesse TCP-Retransmissions auslösen.
Sie benötigen Unterstützung?
Von Kernel-Tuning über NUMA-Optimierung bis zur Prometheus-basierten Überwachung — wir konfigurieren Ihre Linux-Server für maximale Performance und Stabilität. Profitieren Sie von unserer Expertise in Hochlast-Szenarien, Container-Orchestrierung und Dateisystem-Design.
Linux Administration ansehen →
