Vertiefte Analyse der Linux-System-Performance-Konfiguration

Die Optimierung der Systemleistung unter Linux erfordert ein tiefes Verständnis der Kernel-Interna und der systemd-Ressourcenverwaltung. Dieser Artikel beleuchtet zentrale Stellschrauben, mit denen sich Systeme präzise an spezifische Arbeitslasten anpassen lassen – insbesondere in anspruchsvollen Szenarien wie Virtualisierung, Hochleistungs-Datenbanken oder HPC-Umgebungen.

1. Virtual Memory (VM) optimieren mit sysctl

Die Dateien /etc/sysctl.conf oder besser /etc/sysctl.d/*.conf dienen als primäre Schnittstelle zur Modifikation von Kernel-Laufzeitparametern.

Swapping & Speicherdruck

vm.swappiness (0–100)
Reguliert die Neigung des Kernels, Speicherseiten auszulagern.
- Niedrig (1–10): Gut für Datenbanken, In-Memory-Caches.
- 0 verhindert Swapping nicht vollständig, sondern nur bis zum Extremfall.
Kombination: vm.swappiness = 0 vm.min_free_kbytes = 524288 # ca. 5 % RAM reservieren

→ Verhindert unnötiges Swappen bis zum letzten Moment, ohne den OOM-Killer zu triggern.

Dirty Pages & Schreib-I/O

vm.dirty_ratio (Default 20): Maximaler Anteil dirty Pages.
vm.dirty_background_ratio (Default 10): Ab diesem Wert schreibt der Kernel asynchron zurück.
vm.dirty_expire_centisecs: Zeitspanne, wie lange Pages dirty sein dürfen.

Für write-intensive Workloads (z. B. Logging):

vm.dirty_background_ratio = 5
vm.dirty_expire_centisecs = 6000

Weitere Speicher-Parameter

vm.overcommit_memory
- 0: Standardheuristik
- 1: Aggressives Overcommit (z. B. HPC, wissenschaftliche Anwendungen)
- 2: Strikter Modus
vm.overcommit_ratio: Verhältnis RAM+Swap, das für malloc() zugesichert werden darf.

2. Block-I/O und Dateisysteme

I/O-Scheduler

none / noop – ideal für VMs und NVMe/SSD.
mq-deadline – guter Allrounder für SATA/SAS-HDDs.
bfq – Fairness, gut für Desktops.
kyber – niedrige Latenz, experimentell.

cat /sys/block/sda/queue/scheduler

Mount-Optionen

noatime: Keine Zugriffszeit schreiben.
relatime (Default): atime nur bei Bedarf aktualisieren.
discard (nur für SSD sinnvoll, besser via fstrim.timer).
ext4: data=writeback → Schneller, aber riskant (Metadaten-only-Journaling).

3. Ressourcensteuerung mit systemd & cgroups

systemd (ab v219) nutzt cgroups v2 für feingranulare Ressourcenverwaltung.

Beispiel mysql.service:

[Service]
CPUAffinity=0 1
MemoryMax=8G
MemoryHigh=6G
CPUShares=1024
IOWeight=100
BlockIOReadBandwidth=/dev/sda 10M
BlockIOWriteBandwidth=/dev/sdb 50M
TasksMax=10000

Aktivierung:

sudo systemctl daemon-reload
sudo systemctl restart mysql

4. CPU- und NUMA-Optimierung

CPU-Governor

sudo cpupower frequency-set -g performance

performance → Fix höchster Takt (empfohlen für Server).
schedutil → Dynamisch, gut für moderne CPUs.

Prozessaffinität

CPU-Pinning: taskset -cp 0,2,4-6 <pid>
NUMA-Binding: numactl --cpunodebind=0 --membind=0 /usr/bin/app

Hilfreiche Tools: numastat, hwloc.

5. Zusätzliche Optimierungstechniken

Transparent Huge Pages (THP)

Für Datenbanken oft kontraproduktiv → deaktivieren:

echo never > /sys/kernel/mm/transparent_hugepage/enabled

Klassische HugePages

Für DBs (Postgres, Oracle, MySQL) sinnvoll, reduziert TLB-Misses:

vm.nr_hugepages = 2048

IRQ-Affinität

Interrupts auf mehrere CPUs verteilen:

cat /proc/interrupts
echo 2 > /proc/irq/32/smp_affinity

Tools: irqbalance, tuned-adm.

6. Monitoring & Analyse

Optimierung ohne Messung ist sinnlos.

perf – Profiler für CPU-Events, Cache-Misses.
ftrace / trace-cmd – Kernel-Tracing.
iostat -xzm 1 – I/O-Statistiken.
pidstat -d – I/O pro Prozess.
vmstat 1 – Virtueller Speicher.
bcc/eBPF (biolatency, execsnoop, tcpconnect) – moderne Tiefenanalyse.

7. Best-Practice-Tabellen

Empfohlene Kernel-Parameter nach Workload

Workload	Swappiness	I/O-Scheduler	CPU-Governor	atime	Sonstiges
Datenbank	1–10	noop/none (SSD), mq-deadline (HDD)	performance	noatime	THP off, HugePages on
Webserver	10–30	none (SSD)	performance/schedutil	relatime	tcp_tw_reuse=1
Virtualisierung	10–20	none/noop	performance	relatime	IRQ balancing
HPC/Scientific	0–5	noop	performance	noatime	overcommit_memory=1
Desktop	30–60	bfq	schedutil	relatime	Fairness wichtiger

8. TOTE-Modell: Systematisch optimieren

Die Suche nach optimaler Konfiguration ist ein Regelkreis nach dem TOTE-Prinzip:

Test: Ausgangszustand messen (perf, iostat, vmstat).
Operate: Eine gezielte Änderung (z. B. swappiness=10).
Test: Erneut messen, mit Baseline vergleichen.
Exit: Beibehalten oder Hypothese anpassen.

So vermeidet man „Blindflug-Tuning“.

9. Fazit

Linux bietet enorme Stellschrauben für Performance-Optimierung – von VM-Parametern über I/O-Scheduler, cgroups bis hin zu NUMA-Binding. Entscheidend ist nicht die bloße Änderung von Parametern, sondern ein messbasierter Ansatz. Nur durch systematisches Vorgehen nach dem TOTE-Modell lassen sich stabile, nachhaltige Leistungssteigerungen erzielen.

Linux Performance Tuning