Erweiterter Leitfaden zur Optimierung des Linux-Kernels und zur Reduzierung der Latenz

Informatec Digital » Ressourcen » Erweiterter Leitfaden zur Optimierung des Linux-Kernels und zur Reduzierung der Latenz

Wenn es um die Performance unter Linux geht, läuft fast alles auf dasselbe hinaus: den Kernel als zentrale Komponente, die Latenz, Stabilität und Ressourcennutzung steuert . Seine Feinabstimmung kann den entscheidenden Unterschied ausmachen zwischen einem System, das gerade so funktioniert, und einem, das auf Servern, Desktop-PCs, in Cloud-Umgebungen oder sogar auf sehr alter Hardware reibungslos läuft.

Dieser Leitfaden konzentriert sich darauf, wie Sie den Linux-Kernel optimieren können, um die Latenz zu minimieren, ohne Kompromisse bei Sicherheit oder Wartbarkeit einzugehen . Wir behandeln alles von grundlegenden Architekturkonzepten bis hin zu Anpassungen mit sysctl, dem Kompilieren benutzerdefinierter Kernel, der Verwendung von Echtzeit-Patches, der Optimierung für Netzwerke mit niedriger Latenz (wie EC2) sowie Überwachungs- und Benchmarking-Techniken, um zu messen, ob Ihre Optimierungen die Leistung tatsächlich verbessern.

Linux-Kernel-Architektur und wichtige Aspekte der Latenz

Der Linux-Kernel fungiert als Vermittlungsschicht zwischen Anwendungen und Hardware und verwaltet Speicher, Prozesse, Interrupts, Treiber und Dateisysteme . Sein monolithischer, aber dennoch modularer Aufbau ermöglicht dank ladbarer Module die flexible Aktivierung oder Deaktivierung von Funktionen, ohne dass das gesamte System neu kompiliert werden muss.

Um die Ursache von Latenz zu verstehen, ist es entscheidend, mehrere Subsysteme zu kennen: den Prozess-Scheduler , die Speicherverwaltung und die Interrupt-Verarbeitung. Ein schlecht konfigurierter Scheduler, eine aggressive Speicherrichtlinie oder eine übermäßige Anzahl unkontrollierter Interrupts können selbst bei leistungsstarker Hardware zu langsamen Reaktionszeiten führen.

Kernel-Konfigurationsoptionen wie CONFIG_PREEMPT, CONFIG_PREEMPT_VOLUNTARY und CONFIG_SMP spielen hier eine Rolle . Sie bestimmen, inwieweit der Kernel unterbrochen werden kann, um dringendere Aufgaben zu erledigen, und wie er Mehrkernsysteme handhabt. Die Wahl des geeigneten Unterbrechungsmodells verändert die wahrgenommene Latenz auf Desktop-PCs, Servern mit niedriger Latenz oder industriellen Systemen erheblich.

Bei modernen Servern spielt auch die Hardwaretopologie eine wichtige Rolle: Kernverteilung, Sockel, NUMA und Cache-Hierarchie . Durch die Feinabstimmung der CPU-Affinitäten und NUMA-Richtlinien (z. B. durch die Zuweisung von Prozessen und Speicher zum selben Knoten) lassen sich Zugriffszeiten verkürzen und die Cache-Trefferrate verbessern, was entscheidend ist, um Jitter und unvorhersehbare Latenzen zu minimieren.

Darüber hinaus bestimmt das Zusammenspiel zwischen CPU-Scheduler und E/A-Subsystemen (Festplatte und Netzwerk) den Gesamtdurchsatz und die Latenz, die Anwendungen erfahren. Vor jeglichen Änderungen empfiehlt es sich, den aktuellen Zustand (Kernel-Konfiguration, sysctl, GRUB, geladene Module) zu dokumentieren, um bei Leistungseinbußen durch eine Änderung ein schnelles Rollback zu ermöglichen.

Anpassungen über sysctl zur Verbesserung von Latenz und Leistung

Die sysctl-Schnittstelle ermöglicht die dynamische Änderung von Kernelparametern über /proc/sys, ohne dass eine Neukompilierung erforderlich ist. Sie ist der ideale Einstiegspunkt für Optimierungen, ohne sich in langwierigen Kompilierungen zu verlieren.

In Netzwerkumgebungen beeinflussen Parameter wie net.core.rmem_max, net.core.wmem_max und net.ipv4.tcp_congestion_control direkt Durchsatz, Latenz und das Verhalten von TCP-Verbindungen. Die korrekte Anpassung von Puffern und des Staualgorithmus ist für stark frequentierte Webserver oder Cloud-Instanzen mit geringer Latenz unerlässlich.

Für den Arbeitsspeicher ermöglichen Werte wie `vm.swappiness`, `vm.dirty_ratio`, `vm.vfs_cache_pressure` und `vm.overcommit_memory` die Steuerung der Auslagerungsspeichernutzung, der Verwaltung des Seitencaches und des Verhaltens des virtuellen Speichers. Eine Reduzierung der Swappiness (z. B. auf 10) verhindert in der Regel eine zu häufige Auslagerungsspeichernutzung und verringert somit Latenzspitzen aufgrund von Festplattenzugriffen.

Bei der Arbeit mit großen Datenbanken oder Anwendungen, die große Mengen an gemeinsam genutztem Speicher verwenden, ist es entscheidend, die Parameter `kernel.shmmax`, `kernel.shmall` sowie die maximale Anzahl offener Dateien (mittels `fs.file-max` und `fs.nr_open`) anzupassen . Falsch dimensionierte Grenzwerte können zu Engpässen und Fehlern führen, die unter Last schwer zu diagnostizieren sind.

Es empfiehlt sich, Änderungen schrittweise vorzunehmen, deren Auswirkungen mithilfe von Überwachungstools zu messen und sie erst dann in `/etc/sysctl.conf` oder `/etc/sysctl.d/` zu speichern . In Containerumgebungen ist zu beachten, dass viele Kernelparameter für den gesamten Host global gelten: Unachtsame Änderungen können alle Dienste beeinträchtigen. Daher ist die Kombination von `sysctl` mit `cgroups` und Namespaces nahezu unerlässlich.

Kompilieren und Warten von benutzerdefinierten Kerneln

Das Kompilieren eines eigenen Kernels ist nach wie vor ein leistungsstarkes Werkzeug, um Latenzzeiten zu reduzieren, unnötigen Overhead zu beseitigen oder ungewöhnliche Hardware zu unterstützen . Obwohl Distributionen recht vielseitige Kernel enthalten, kann ein spezifischer Kernel in bestimmten Szenarien den entscheidenden Unterschied machen.

Der klassische Arbeitsablauf beinhaltet das Herunterladen des Codes von kernel.org oder gepatchte Trees wie xanmod oder Likörund nutzen Sie Werkzeuge wie make menuconfig Sie können Optionen auswählen. Durch das Speichern der .config-Datei in Ihrem eigenen Git-Repository zusammen mit den Build-Skripten können Sie Builds reproduzieren und die Konsistenz zwischen den Versionen gewährleisten.

Bei Verwendung von Debian oder einer davon abgeleiteten Distribution ist es sehr praktisch, „ nach Debian-Art “ zu kompilieren, um .deb-Pakete für Kernel, Header und zugehörige Bibliotheken zu erhalten. So können Sie den angepassten Kernel auf mehreren Rechnern bereitstellen, indem Sie einfach die Pakete installieren und die Versionen über Ihr eigenes Repository verwalten.

In der Praxis ist das manuelle Kompilieren oft sinnvoll, wenn man mit alter oder sehr leistungsschwacher Hardware arbeitet . Ein typisches Beispiel ist ein altes Netbook mit Atom-Prozessor und 1 GB RAM. Ein moderner, generischer Kernel mit unnötigen Treibern und Serveroptionen würde hier Latenz und zusätzliche CPU-Auslastung verursachen, die man sich nicht leisten kann.

Eine gängige Strategie besteht darin, mit der aktuellen Kernelkonfiguration zu beginnen (z. B. durch Kopieren der Konfigurationsdatei aus /boot ) und diese anschließend anzupassen. Sie können das Präemptionsmodell auf „ Preemptibler Kernel (Desktop mit niedriger Latenz) “ ändern, um die interaktive Reaktionsfähigkeit des Desktops zu priorisieren, oder spezifische E/A-Scheduler wie BFQ als Modul hinzufügen, um die Leistung auf mechanischen Festplatten zu verbessern.

Um lange Kompilierungszeiten zu vermeiden, empfiehlt es sich, auf einem leistungsstärkeren Rechner zu arbeiten und gegebenenfalls Cross-Compiling zu verwenden (z. B. einen 32-Bit-Kernel für einen Atom-Prozessor von einem x86_64-PC zu kompilieren, indem man einfach ARCH und die zugehörigen Toolchains anpasst). Anschließend müssen nur noch die .deb-Dateien auf dem Zielrechner installiert und der entsprechende Eintrag in GRUB hinzugefügt werden.

Die Schwierigkeit liegt in der Wartung: Es empfiehlt sich, den neuen Kernel auf Knoten der Kanarischen Inseln zu testen , klare Rollback-Pfade im Bootmanager zu haben und während der Umstellung Protokolle und Metriken aufzuzeichnen, um Regressionen bei der Leistung oder der Treiberkompatibilität zu erkennen.

Präemptionsmodelle und PREEMPT_RT-Patches für Systeme mit niedriger Latenz

Das Präemptionsmodell des Kernels legt fest, in welchem ​​Umfang ein laufender Prozess unterbrochen werden kann, damit ein Prozess mit höherer Priorität ihn übernehmen kann, was sich direkt auf die Antwortzeit auswirkt . Dies umfasst sowohl Standardkonfigurationsoptionen als auch Echtzeit-Patches.

Generische Kernel bieten verschiedene Optionen: keine Präemption (mit Fokus auf Serverdurchsatz), freiwillige Präemption und einen präemptiven Kernel für Desktop-Systeme , der schnelle Reaktionszeiten für interaktive Anwendungen priorisiert. Durch Anpassen dieser Einstellung lässt sich die Leistung von Desktop-Systemen, Audioanwendungen oder auch älteren, stark ausgelasteten Rechnern deutlich verbessern.

Wenn noch ein Schritt weiter gehen muss, kommen die Patches PREEMPT und PREEMPT_RT zum Einsatz , die wichtige Teile des Kernels modifizieren, um nicht unterbrechbare Abschnitte zu minimieren. PREEMPT_RT ist für Systeme vorgesehen, bei denen die Latenz im schlimmsten Fall (nicht nur im Durchschnitt) sehr niedrig und vorhersagbar sein muss: Industrieautomation, professionelle Audiotechnik, Telekommunikation oder Hochfrequenzhandel.

Die Entscheidung zur Einführung von PREEMPT_RT sollte nicht auf Trends, sondern auf konkreten Latenz- und Jittermessungen basieren . Zunächst empfiehlt es sich, die Scheduler-Einstellungen, CPU-Affinitäten, sysctl und gegebenenfalls Konfigurationen wie Dynamic Tickless gründlich zu untersuchen, bevor die Wartung durch einen RT-Baum verkompliziert wird.

Auch die Kompatibilität muss berücksichtigt werden: Einige Treiber und Subsysteme sind nicht vollständig an RT angepasst und benötigen möglicherweise spezielle Versionen oder zusätzliche Patches. Es empfiehlt sich, einen Wartungsplan zu erstellen, der klar festlegt, wann und wie neue Versionen des Hauptkernels in den RT-Zweig integriert werden, der zwar regelmäßig synchronisiert wird, aber dennoch etwas hinterherhinkt.

CPU-Scheduling-Optimierung, tickloser Betrieb und Kernisolierung

Neben der Wahl des Präemptionsmodells können Sie die Latenz auch durch Experimentieren mit der CPU-Planung und dem Verhalten des Kernel-Timers feinabstimmen, insbesondere bei unternehmensorientierten Distributionen wie RHEL.

Red Hat Enterprise Linux 8 beispielsweise verwendet standardmäßig einen tickless Kernel für CPUs im Leerlauf . Dieser reduziert den Stromverbrauch, indem er periodische Interrupts vermeidet, wenn der Kernel im Leerlauf ist. Für latenzkritische Workloads kann ein dynamischer tickless Modus für mehrere Kernel aktiviert werden . Dadurch übernimmt nur eine CPU (der „Home-Kernel“) die meisten Timing-Aufgaben, während die übrigen Kernel weitestgehend von periodischen Interrupts befreit werden.

Diese Konfiguration erfolgt durch Hinzufügen geeigneter Parameter zu die Kernel-Befehlszeile in GRUBdie Konfiguration neu zu generieren und anschließend die Affinität kritischer Kernel-Threads, wie z. B. RCU-Threads oder Threads, anzupassen bdi-flushsodass sie sich im für die Wartung reservierten Kernbereich befinden.

Dieser Ansatz lässt sich durch den Parameter `isolcpus` ergänzen , der es ermöglicht, Kerne von normalen Benutzerprozessen zu isolieren. In Szenarien mit geringer Latenz ist es üblich, mehrere Kerne exklusiv für eine kritische Anwendung zu reservieren, während der Rest des Systems (Daemons, Interrupts usw.) von anderen Kernen verarbeitet wird.

Um zu überprüfen, ob der dynamische ticklose Modus funktioniert, können einfache Tests durchgeführt werden mit stress oder Skripte, die die CPU für eine Sekunde beschäftigen und beobachten mit Timer-Tickzähler Wie die Anzahl der Interrupts pro Sekunde in isolierten Kernen von Tausenden auf nur noch einen sinkt, ist ein Zeichen dafür, dass der periodische Timer verschwunden ist.

Speicher- und Speichermanagement mit Fokus auf Latenz

Die Art und Weise, wie der Kernel Speicher- und Festplatten-E/A verwaltet, hat einen großen Einfluss auf die von Anwendungen wahrgenommene Latenz , insbesondere bei Datenbanken und Diensten, die viele kleine, häufige Operationen durchführen.

Auf der Speicherseite minimiert die Reduzierung von vm.swappiness die Swap-Nutzung (die fast immer viel langsamer ist als RAM), vm.vfs_cache_pressure steuert, wie schnell das System den Inode- und Dentry-Cache freigeben muss, und vm.nr_hugepages ermöglicht es Ihnen, statische HugePages für hohe Lasten wie Datenbanken oder JVMs zu reservieren, wodurch der TLB-Overhead reduziert wird.

Im Lager wählen Sie die Geeigneter E/A-Scheduler je nach Festplattentyp Das ist unerlässlich. Bei modernen SSDs ist es in der Regel ratsam, ... zu verwenden. none o mq-deadlineBei mechanischen Festplatten und Multitasking-Systemen sind hingegen Algorithmen, die auf Fairness ausgelegt sind, möglicherweise besser geeignet, wie zum Beispiel BFQDarüber hinaus können Dateisysteme mit Optionen wie noatime y nodiratime Vermeiden Sie unnötige Schreibvorgänge bei jedem Zugriff auf eine Datei oder ein Verzeichnis.

Bei Dateisystemen sind ext4 und XFS nach wie vor die gängigsten Optionen: Ein gut konfiguriertes ext4 bietet Sicherheit, während XFS bei hoher gleichzeitiger Nutzung tendenziell besser skaliert. In besonders anspruchsvollen Szenarien kann die Kombination von RAID (RAID 10 für Datenbanken, RAID 0 für temporären Scratch-Speicher) mit einem guten Scheduler die durchschnittliche Latenz und vor allem die Variabilität reduzieren.

Netzwerk- und Kerneloptimierung für geringe Latenz in Linux und EC2

In leistungsstarken Netzwerkanwendungen hängt die Latenz nicht nur von der Hardware oder der Entfernung ab, sondern auch von der Konfiguration des TCP/IP-Stacks und des Kernels selbst . Dies macht sich besonders bei Cloud-Instanzen wie Amazon EC2 mit ENA-Schnittstellen bemerkbar.

Zunächst ist es wichtig, externe Faktoren wie die Anzahl der Netzwerk-Hops , die Pakete durchlaufen, zu reduzieren: Durch die Verwendung direkterer Topologien, Load Balancer in der Nähe des Backends oder optimierte Verfügbarkeitszonen wird die Laufzeit in Millisekunden verkürzt, bevor die Pakete überhaupt das Betriebssystem erreichen.

Innerhalb des Kernels umfasst die Netzwerkkonfiguration die Erhöhung der Dateideskriptoren (ulimit -n) , die Dimensionierung der Empfangs- und Sendepuffer mit net.core.rmem_max, net.core.wmem_max, net.ipv4.tcp_rmem, net.ipv4.tcp_wmem sowie die Aktivierung von Optionen wie TCP Fast Open , um die Latenz beim Verbindungsaufbau zu reduzieren.

Bei AWS ENA-Schnittstellen spielt die Interrupt-Moderation eine wichtige Rolle: Standardmäßig gruppiert der Treiber Pakete, um die Anzahl der IRQs zu reduzieren. rx-µs und tx-µsWenn Sie die Latenz auf ein absolutes Minimum reduzieren möchten, können Sie diese Moderation deaktivieren, indem Sie ethtool -CDurch das Setzen von rx-usecs und tx-usecs auf Null wird die Latenz verringert, aber der Interrupt-Overhead erhöht sich, daher muss je nach Last ein Gleichgewicht gefunden werden.

Sie können auch irqbalance verwenden, um IRQs auf mehrere Kerne zu verteilen , oder es deaktivieren und Interrupt- und Netzwerkwarteschlangen-Affinitäten (RSS/RPS) manuell bestimmten Kernen zuweisen, was in Umgebungen mit extrem niedriger Latenz oder bei Verwendung von DPDK und Überspringen eines großen Teils des Kernel-Stacks sehr häufig vorkommt.

Ein weiterer zu berücksichtigender Parameter sind die C-States der CPU : Tiefschlafzustände reduzieren zwar den Stromverbrauch, führen aber zu Verzögerungen beim Aufwachen des Kerns. Um die Reaktionszeit zu verkürzen, können diese Tiefschlafzustände begrenzt werden, was einen höheren Stromverbrauch und weniger Spielraum für Turbo Boost auf anderen Kernen zur Folge hat. Jede Umgebung bietet ein optimales Verhältnis zwischen Stromverbrauch und gewonnenen Mikrosekunden.

CPU-, Service- und Anwendungsoptimierung zur Reduzierung der Latenz

Neben dem Kernel selbst hat auch die Umgebung viel über die Gesamtlatenz zu sagen: von den auf dem System aktiven Diensten bis hin zur spezifischen Konfiguration jeder Anwendung.

Ein Hochleistungsserver sollte nur die folgenden Funktionen ausführen: Dämonen, die wirklich notwendig sindDienste wie Bluetooth, Drucken oder die automatische Netzwerkerkennung (CUPS, Avahi usw.) auf Backend-Rechnern verbrauchen unnötig CPU, Arbeitsspeicher und E/A, ohne einen Nutzen zu bringen. (Überprüfung erforderlich) systemctl list-unit-files --state=enabled Und das Deaktivieren unnötiger Funktionen ist eine der günstigsten und effektivsten Maßnahmen, die man ergreifen kann.

Zur Priorisierung kritischer Prozesse können Tools wie renice, chrt und taskset verwendet werden . Durch Anpassen der Priorität eines Prozesses (renice), Zuweisen von Echtzeit-Scheduling (chrt -f 99) oder Zuweisen zu bestimmten Kernen (taskset) werden Interferenzen mit anderen Aufgaben reduziert und die CPU-Vorhersagbarkeit für Datenbanken, VoIP, Streaming oder Handelsdienste verbessert.

Auf Anwendungsebene ist die Optimierung genauso wichtig wie die des Kernels. Webserver wie Nginx oder Apache benötigen eine Feinabstimmung von Worker-Knoten, Keepalive-Funktionen, Caches und Komprimierung. Datenbanken wie PostgreSQL oder MySQL erfordern die Überprüfung von Puffergrößen, Checkpoints, Verbindungspools und Parametern für synchrone Schreibvorgänge, um eine niedrige und stabile Latenz zu erreichen.

Die JVM spielt ebenfalls eine Rolle: Durch die Auswahl von Garbage Collectoren wie G1GC oder ZGC und die Anpassung der Heap-Größe lassen sich Pausen reduzieren, die von außen als Latenz wahrgenommen werden. In virtualisierten und containerisierten Umgebungen verhindert die korrekte Zuweisung von vCPU-, vRAM- und I/O-Kontingenten unbemerkte Konflikte, die sich später in endlosen Festplattenwarteschlangen oder einer CPU-Überlastung äußern.

Kernel- und Systemüberwachung und Benchmarking

All diese Optimierungen sind nutzlos, wenn man die Auswirkungen nicht misst. Entscheidend ist die Kombination von kontinuierlicher Überwachung mit reproduzierbaren Leistungstests , damit jede Änderung am Kernel oder an sysctl anhand objektiver Daten bewertet werden kann.

Um den Gesamtstatus des Systems zu ermitteln, können Sie klassische Werkzeuge wie beispielsweise verwenden htop, vmstat, iotop o sarWenn Sie mehr Details benötigen, kommen spezielle Kernel-Tools zum Einsatz, wie zum Beispiel perf und ftracedie es Ihnen ermöglichen, das Verhalten des Schedulers, von Interrupts und internen Aufrufen mit erheblicher Genauigkeit zu verfolgen.

In Produktionsumgebungen empfiehlt sich der Einsatz von Metriksystemen wie Prometheus, collectd oder sysstat mit Exportern, die CPU-Zähler, E/A-Latenzen, Festplatten- und Netzwerklatenzen, Prozesswarteschlangen usw. bereitstellen. Die Visualisierung dieser Daten in Grafana oder ähnlichen Tools hilft, Regressionen oder Anomalien zu erkennen, bevor der Endbenutzer Probleme bemerkt.

Beim Benchmarking geht es darum, die tatsächliche Arbeitslast zu simulieren und die Ergebnisse vor und nach jeder Änderung zu vergleichen. Tools wie sysbench (für CPU und Datenbanken), fio (für Festplatten) oder iperf3 (für Netzwerk) ermöglichen die Erstellung reproduzierbarer Szenarien. Es ist unerlässlich, Kernelversionen, sysctl-Konfigurationen, Hardware und Testparameter zu dokumentieren , um aussagekräftige Vergleiche über die Zeit zu gewährleisten.

In der Praxis ist die Linux-Kernel-Optimierung ein iterativer Prozess: Man testet verschiedene Anpassungen, misst die Ergebnisse, behält die nutzbringenden bei und verwirft den Rest. Mit einem guten Änderungsmanagement lassen sich die Verbesserungen neuer Kernel-Versionen (z. B. aktuelle Serien mit Scheduler-, Grafik-, Energie- oder Netzwerk-Optimierungen) in messbare Vorteile für Ihre Anwendungen umsetzen – egal ob auf lokalen Servern, in der Cloud oder auf anspruchsvollen Workstations.

Die Kombination aus Kernel-Architekturwissen, Feinabstimmung mit sysctl, kontrollierter Kompilierung, selektivem Einsatz von Echtzeit-Patches und einem guten Metriksystem ermöglicht es einem Administrator oder Betriebsteam, schnellere Reaktionszeiten, geringere Latenzen und eine bessere Gesamtstabilität zu erreichen , ohne bei der geringsten Provokation die Hardware ändern oder die Systemsicherheit beeinträchtigen zu müssen.