Der Linux-Kernel: Scheduler, Speicher, VFS, Systemstart und Fehlerdiagnose

EdwardMoon

Der Linux-Kernel ist die zentrale Betriebssystemschicht, über die Anwendungen CPU, Arbeitsspeicher, Datenträger und Netzwerk kontrolliert gemeinsam nutzen. Prozesse rufen Kernel-Funktionen nicht unmittelbar auf, sondern fordern Dienste über das Systemaufruf-ABI an. Der Kernel prüft Berechtigungen und Ressourcenzustand, bevor er Hardwareoperationen ausführt.

Dieser Artikel geht über die Einordnung als monolithischer Kernel hinaus. Anhand von Diagnosebefehlen für reale Server werden die Zusammenhänge zwischen Scheduling, virtuellem Speicher, VFS, Systemstart, Modulen und Panics erläutert. Dazu gehört der Grundsatz, keine unbegründeten sysctl-Empfehlungen ungeprüft anzuwenden.

Der Kernel-Aufbau im Überblick

Linux ist ein monolithischer Kernel: leistungsrelevante Komponenten wie Scheduler, Speicherverwaltung, VFS, Netzwerkstack und die meisten Treiber laufen im Kernel-Adressraum. Gleichzeitig unterstützt Linux ladbare Kernel-Module, mit denen Funktionen während des Betriebs ergänzt oder entfernt werden können. CPU-Privilegstufen und der Schutz der Seitentabellen trennen Benutzer- und Kernelraum.

Aktuellen Kernel und Ausführungsumgebung feststellen

uname -a
cat /etc/os-release
cat /proc/cmdline
systemd-detect-virt
cat /proc/sys/kernel/tainted

Ist der letzte Wert ungleich null, kann der Kernel beispielsweise durch ein proprietäres Modul, erzwungenes Entfernen eines Moduls oder Hardwarefehler als tainted markiert sein. Ziehen Sie aus der Zahl allein keinen Schluss. Prüfen Sie die offizielle Beschreibung der Taint-Bits zusammen mit den Kernel-Protokollen.

Zentrale Kernel-Subsysteme

Die Grenze der Systemaufrufe

Anwendungen verwenden häufig libc-Wrapper, müssen aber nicht zwingend über libc gehen. Sie können auch unmittelbar die architekturspezifische Systemaufrufinstruktion und Aufrufkonvention nutzen. Der Kernel prüft Nummer, Argumente und Berechtigungen des Systemaufrufs und leitet ihn an seine interne Implementierung weiter. Präzise ist daher: glibc stellt häufig praktische Wrapper bereit; glibc selbst verarbeitet nicht die eigentlichen Systemaufrufe.

Das Öffnen einer Datei mit strace verfolgen

strace -f -e trace=openat,read,write,close cat /etc/hostname

# Nur die zusammengefassten Statistiken anzeigen
strace -c cat /etc/hostname

In aktuellen glibc-Umgebungen kann ein Dateizugriff statt als open() als Aufruf aus der openat()-Familie erscheinen. Der Name einer Benutzerraumfunktion muss nicht mit dem tatsächlich ausgeführten Systemaufruf übereinstimmen.

CFS und EEVDF

Das Scheduling gewöhnlicher Linux-Tasks ist präemptiv. CFS als nichtpräemptiven Scheduler zu beschreiben, ist falsch. Ab Kernel 6.6 begann außerdem der Übergang vom CFS-Modell mit virtueller Laufzeit zu EEVDF. Distributionen können Änderungen zurückportieren. Leiten Sie das Verhalten deshalb nicht allein aus dem Namen ab, sondern prüfen Sie die tatsächliche Kernel-Version und die Dokumentation des Anbieters.

uname -r
ps -eo pid,tid,psr,cls,pri,ni,stat,comm --sort=-pri | head -n 20
chrt -p $$
cat /proc/$$/sched | head -n 30

Virtueller Speicher und Seitencache

Die für einen Prozess sichtbaren virtuellen Adressen werden über MMU und Seitentabellen auf physischen Speicher oder Dateien abgebildet. Anonymer Speicher, Dateimappings, Seitencache, Slab, Speicherrückgewinnung und Swap beeinflussen sich gegenseitig. Beurteilen Sie Speichermangel nicht nur anhand der Spalte free des Befehls free. Berücksichtigen Sie auch available, Swap, Seitenfehler, Reclaim und PSI.

free -h
grep -E 'MemAvailable|Cached|Swap|Slab|SReclaimable' /proc/meminfo
vmstat 1 10
cat /proc/pressure/memory
ps -eo pid,comm,rss,vsz,%mem --sort=-rss | head -n 20

Den Adressraum eines Prozesses prüfen

PID=1234
pmap -x "$PID" | tail -n 20
cat "/proc/$PID/status" | grep -E 'VmRSS|VmSwap|Threads'
cat "/proc/$PID/smaps_rollup"

VmRSS umfasst gemeinsam genutzte Seiten. Werden die Werte aller Prozesse einfach addiert, kann das Ergebnis deshalb über dem tatsächlich belegten physischen Speicher liegen. Verwenden Sie smaps_rollup, wenn Sie gemeinsam genutzten Speicher über PSS anteilig betrachten möchten.

VFS und Datei-I/O

VFS stellt eine gemeinsame Schnittstelle für Implementierungen wie ext4, XFS, Btrfs und NFS bereit. Ein Pfadname wird unter Einbeziehung des Dentry-Caches zu einem Inode aufgelöst. Eine geöffnete Datei wird aus der Dateideskriptortabelle des Prozesses über ein file-Objekt im Kernel referenziert. Diese Referenzen erklären auch, warum ein gelöschter Dateipfad verschwinden kann, während seine Blöcke weiterhin belegt bleiben, solange ein Prozess die Datei geöffnet hält.

cat /proc/filesystems
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS
stat /var/log/messages
sudo lsof +L1
cat /proc/sys/fs/file-nr

Unterscheiden Sie bei Speicherplatzfehlern zwischen belegten Blöcken, erschöpften Inodes und geöffneten, bereits gelöschten Dateien. Den vollständigen Ablauf beschreibt die Diagnoseanleitung zu No space left on device.

Systemstart und initramfs

Ein typisches UEFI-System startet über Firmware, Bootloader, Kernel und initramfs, das tatsächliche Root-Dateisystem und schließlich PID 1. initramfs wird gewöhnlich als komprimiertes cpio-Archiv bereitgestellt und enthält den frühen Benutzerraum. Dieser bereitet Module und Werkzeuge für Speichergeräte, Verschlüsselung, LVM und RAID vor und wechselt anschließend zum tatsächlichen Root-Dateisystem.

1. Die Firmware wählt einen Starteintrag und führt den Bootloader oder EFI-Stub aus.
2. Der Kernel initialisiert CPU, Speicher, Interrupts und frühe Treiber.
3. Der frühe Benutzerraum im initramfs bereitet das tatsächliche Root-Gerät vor.
4. Nach switch_root startet PID 1 aus dem tatsächlichen Root-Dateisystem die Dienste und Anmeldeumgebung.

cat /proc/cmdline
systemd-analyze time
systemd-analyze critical-chain
journalctl -b -k -p warning

# Unter RHEL/Rocky den Inhalt des aktuellen initramfs prüfen
lsinitrd "/boot/initramfs-$(uname -r).img" | less

Kernel-Module und Treiber diagnostizieren

Module laufen mit hohen Privilegien innerhalb des Kernels. Ihre Fehler haben daher andere Auswirkungen als Fehler gewöhnlicher Benutzerprogramme. Fehlt ein Gerät, entfernen und laden Sie Module nicht wahllos neu. Prüfen Sie zunächst das Gerät, den zugeordneten Treiber, die Modulsignatur und die Kernel-Protokolle.

lspci -nnk
lsmod | head
modinfo <module_name>
journalctl -k -b | grep -Ei 'firmware|module|driver|taint|error'
cat /proc/sys/kernel/tainted

modprobe -r kann gerade benötigte Speicher- oder Netzwerktreiber entfernen. Führen Sie den Befehl im Betrieb erst aus, nachdem Abhängigkeiten und Auswirkungen geprüft wurden und ein Wartungsfenster sowie Konsolenzugang bereitstehen.

Kernel-Panics diagnostizieren

Nach einem Kernel Oops kann die Ausführung trotz protokolliertem Kernel-Fehler fortgesetzt werden; die Zuverlässigkeit des Systems kann jedoch bereits beeinträchtigt sein. Bei einer Kernel Panic stellt der Kernel fest, dass eine normale Fortsetzung nicht möglich ist. Je nach Konfiguration hält das System an, startet nach einer Wartezeit neu oder wechselt zu einem Aufnahmekernel für kdump. Eine Panic ist daher nicht grundsätzlich ein sofortiges Herunterfahren zum Schutz des Systems.

journalctl -k -b -1 -p warning..alert
last -x | head -n 20
sudo kdumpctl status
sysctl kernel.panic kernel.panic_on_oops
ls -lh /var/crash

Vorgehen bei einer Panic

• Zeitpunkt der letzten Änderungen an Kernel, Treibern, Firmware oder Hardware feststellen.
• Die vollständige Panic-Ausgabe und den ersten Fehler von Konsole oder Fernverwaltungsgerät sichern.
• Falls kdump bereits vorbereitet war, vmcore und Debug-Symbole des identischen Builds beschaffen.
• Durch Starten des vorherigen Kernels prüfen, ob der Fehler weiterhin auftritt, um Regressionen und Hardwareprobleme einzugrenzen.
• Auf Produktionsservern keine absichtlichen Panic-Auslöser betätigen.

sysctl: messen, Hypothese prüfen und Rücknahme vorbereiten

sysctl --system und sysctl -p wenden Einstellungen auf den laufenden Kernel an. Sie sind weder Syntaxprüfungen noch rein lesende Diagnosebefehle. Ersetzen Sie den folgenden Dateipfad durch eine vorhandene lokale Konfigurationsdatei. Ist eine Anwendung der Einstellungen erforderlich, führen Sie sie gesondert im Wartungsfenster aus und halten Sie vorherige Werte sowie Befehle zur Rücknahme bereit.

Für sysctl gibt es keine universellen Empfehlungswerte für sämtliche Webserver. Engpässe hängen von Kernel-Version, Arbeitsspeicher, Verbindungsmustern, Anwendungswarteschlangen und Containergrenzen ab. Werden insbesondere tcp_tw_reuse, Portbereiche, Backlogs und swappiness ohne Begründung gleichzeitig geändert, wird die Fehlerursache nur schwerer erkennbar.

# 1. Aktuelle Werte und zugehörige Messgrößen lesen.
sysctl vm.swappiness net.core.somaxconn net.ipv4.ip_local_port_range
ss -s
vmstat 1 10

# 2. Konfigurationsdateien nur lesen; keine Werte anwenden.
sudo find /etc/sysctl.d /run/sysctl.d /usr/local/lib/sysctl.d /usr/lib/sysctl.d \
  -maxdepth 1 -type f -name '*.conf' -print 2>/dev/null
sudo cat /etc/sysctl.conf

# 3. Die zu prüfende Datei wählen und ihren Inhalt mit den aktuellen Kernelwerten vergleichen.
sudo cat /etc/sysctl.d/99-local.conf
sysctl vm.swappiness net.core.somaxconn net.ipv4.ip_local_port_range

Ein Diagnoseablauf für zehn Minuten

# 1. Version, Systemstart und Taint-Status
uname -r
uptime
cat /proc/sys/kernel/tainted

# 2. CPU-, Speicher- und I/O-Druck
vmstat 1 10
cat /proc/pressure/{cpu,memory,io}

# 3. Aktuelle Kernelwarnungen und fehlgeschlagene Units
journalctl -k -b -p warning..alert
systemctl --failed

# 4. Dateisysteme und geöffnete, bereits gelöschte Dateien
df -hT
df -i
sudo lsof +L1

Diagnose beginnt nicht mit veränderten Tuning-Werten. Bringen Sie zunächst die Zeitachsen der Beobachtungen in Übereinstimmung. Ermitteln Sie, welche Ressource ausgelastet war und ob zuerst Kernel-Warnungen oder Anwendungsfehler auftraten. Formulieren Sie daraus eine überprüfbare Hypothese.

Häufige Fehlannahmen korrigieren

Offizielle Dokumentation und weiterführende Themen

• Dokumentation des Linux-EEVDF-Schedulers
• Linux-Speicherverwaltung
• Überblick über Linux VFS
• Linux: Einstellungen unter /proc/sys/kernel
• Linux-kdump-Dokumentation
• Isolierte Python-Umgebungen im Benutzerraum

Kernel-Wissen praktisch einsetzen

Den Linux-Kernel zu verstehen bedeutet, Symptome im Benutzerraum mit Systemaufrufen, Scheduler, Speicherverwaltung, VFS und Treibern in Verbindung bringen zu können. Sichern Sie zuerst aktuelle Versionsinformationen und Protokolle. Grenzen Sie den Engpass anhand von Messgrößen auf eine Schicht ein und prüfen Sie anschließend jede Änderung einzeln mit einem vorbereiteten Rücknahmeverfahren.