Erweiterte Linux-Kernel-Optimierung mit sysctl

Informatec Digital » Ressourcen » Erweiterte Linux-Kernel-Optimierung mit sysctl

Wer schon länger Linux-Server verwaltet, wird irgendwann feststellen, dass der Unterschied zwischen einem mittelmäßigen System und einem, das auch unter Volllast reibungslos läuft, in der optimalen Kernel-Optimierung liegt. Es geht nicht nur darum, mehr RAM oder eine leistungsstärkere CPU einzubauen: Viele Engpässe lassen sich durch die Anpassung einiger weniger, sorgfältig gewählter Parameter beheben.

Der Kernel stellt Hunderte von Netzwerk-, Speicher-, Dateisystem- und Prozessplanungsoptionen bereit, die dynamisch angepasst werden können. Mit dem Tool sysctl und einige Anpassungen in /procEs ist möglich, das Maximum aus der Hardware herauszuholen und Folgendes zu erreichen: Geringere Latenz, höherer Durchsatz und bessere Stabilität Dies gilt für Webserver und Datenbanken ebenso wie für Echtzeitumgebungen und Kubernetes. Es ist jedoch unerlässlich, genau zu wissen, was man tut und wie man es misst.

Was ist sysctl und wie organisiert es Kernelparameter?

Dienstprogramm sysctl Es ist das Tor zur Änderung von Kernelparametern, ohne dass eine Neukompilierung oder ein Neustart erforderlich ist, und ermöglicht Werte zur Laufzeit lesen und ändern Konfigurationen lassen sich sofort testen. Diese Parameter sind in einer niedrigen hierarchischen Struktur organisiert. /proc/sys/und jede dieser Funktionen steuert ein bestimmtes Verhalten des Systems.

Die Einstellungen sind in übersichtliche Kategorien unterteilt, sodass Sie bei spezifischen Leistungs- oder Stabilitätsproblemen schnell die benötigten Anpassungen vornehmen können. Dank dieser Struktur können Sie sich beispielsweise gezielt auf Netzwerk (net.*), Arbeitsspeicher (vm.*) oder Dateisystem (fs.*) konzentrieren , ohne sich in den übrigen Kernel-Optionen zu verlieren.

Die Hauptkategorien, die Sie finden werden in /proc/sys/ Dazu gehören unter anderem:

• kernel.*: Allgemeine Kernel-Optionen (Scheduler, PID, Nachrichten, NUMA usw.).
• vm.*: Verwaltung des virtuellen Speichers, Auslagerungsspeicher, Caches und Overcommit-Richtlinien.
• netto.*: IPv4/IPv6-Netzwerkstack, TCP/UDP-Puffer, Warteschlangen, Staukontrolle.
• fs.*: Grenzen von Deskriptoren, Inodes, inotify, AIO und VFS-Verhalten.
• dev.*: spezifische Parameter bestimmter Geräte und Treiber.

Mit sysctl -a Sie können alle verfügbaren Parameter auflisten, beispielsweise mit Befehlen wie sysctl vm.swappiness o sysctl net.ipv4.tcp_tw_reuse das Ablesen spezifischer Werte, was der Schlüssel dazu ist Überprüfen Sie die aktuelle Konfiguration Bevor Sie etwas ändern. Um etwas Bestimmtes zu finden, ist es üblich, mit folgenden Filtern zu arbeiten: grepzum Beispiel: sysctl -a | grep tcp.

Das Ändern eines Parameters im laufenden Betrieb ist so einfach wie die Verwendung von sysctl -w clave=valorEs ist jedoch wichtig zu verstehen, dass diese Änderungen nur temporär sind. Um sie nach einem Neustart zu speichern, ist es unerlässlich, die Konfiguration zu sichern. /etc/sysctl.conf oder in Dateien von /etc/sysctl.d/üblicherweise unter Verwendung nummerierter Dateien (zum Beispiel 10-network.conf, 20-memory.conf, 99-custom.conf) die die Reihenfolge bestimmen, in der sie angewendet werden.

Messen, bevor man etwas anfasst: Benchmarks und Systembasislinie

Bevor Sie an den Einstellungen herumspielen, ist es ratsam, eine objektive Leistungsbasislinie festzulegen . Ohne vorherige Daten lässt sich nicht feststellen, ob die Änderungen das System verbessert oder verschlechtert haben, und Sie tappen in die klassische Falle „Es scheint mir besser zu sein“, die für fundierte Entscheidungen völlig nutzlos ist.

Auf Systemebene ist es ratsam, CPU-, Auslastungs-, Speicher-, Festplatten- und Netzwerkstatistiken über einige Minuten unter repräsentativer Last zu erfassen. Tools wie beispielsweise uptime, mpstat, vmstat, iostat -x o sar -n DEV Sie ermöglichen es Ihnen zu sehen, wie sich der Standardkernel verhält, wie viel Swap-Speicher er verwendet, wie die Festplatten-E/A reagiert und ob das Netzwerk ausgelastet ist oder Bandbreite verschwendet.

Zusätzlich zu dieser Übersicht ist es entscheidend, spezifische Benchmarks für die Anwendung durchzuführen, die Sie optimieren möchten. Auf Webservern können Sie beispielsweise folgende Funktionen nutzen: ab (Apache Bench) oder ähnliche Tools zur Messung Anfragen pro Sekunde, durchschnittliche Latenz und FehlerIn Datenbanken werden Dienstprogramme wie z. B. mysqlslap o sysbench Sie helfen bei der Auswertung von Transaktionen pro Sekunde und Abfragezeiten.

In einem Szenario ohne Optimierung findet man beispielsweise häufig Werte wie 500 HTTP-Anfragen/s mit einer durchschnittlichen Antwortzeit von 200 ms, etwa 250 SQL-Abfragen/s mit einer Latenz von 40 ms, eine Netzwerkgeschwindigkeit von ca. 500 Mbit/s und eine Systemlast nahe ihrer Leistungsgrenze. Anhand dieser Werte lässt sich nach der Anwendung von Kernel-Änderungen überprüfen, ob tatsächlich eine messbare Steigerung des Durchsatzes und eine Reduzierung der Latenz erreicht wurden.

Dokumentieren Sie abschließend die Befehle und Ergebnisse, bevor Sie Änderungen vornehmen. Eine Historie ermöglicht Ihnen den genauen Vergleich verschiedener Anpassungsvorgänge und hilft Ihnen außerdem, Regressionen nach einem Kernel-Update oder der Einführung eines neuen sysctl-Profils in der Produktionsumgebung zu erkennen.

Erweiterte Speichereinstellungen: vm.*

Der Arbeitsspeicher ist eines der Subsysteme, bei denen Kerneländerungen am deutlichsten spürbar sind. Ein Server mit viel RAM, der aber schlecht konfiguriert ist, kann unnötigerweise Auslagerungsspeicher belegen, was zu Problemen führt… I/O-Spitzen und drastische LeistungseinbrücheDeshalb sind Parameter wie vm.swappinessDas Verhältnis von Seiten mit zu vielen Einträgen (Dirty Pages Ratio) oder das Verhalten des VFS-Caches sind genauso wichtig.

Parameter vm.swappiness Diese Einstellung steuert, wie viele Speicherseiten der Kernel in den Auslagerungsspeicher auslagert. In vielen Distributionen ist sie auf 60 gesetzt, ein Wert, der für gemischte Desktop-Umgebungen vorgesehen ist. Für Datenbankserver oder Anwendungen mit geringer Latenz ist es in der Regel ratsam, den Wert auf 10 oder sogar weniger zu senken, um ein effizienteres System zu erzielen. Priorisieren Sie die Speicherung von Daten im RAM und reduzieren Sie das Auslagern.Es ist nicht ungewöhnlich, dass der Festplattenverkehr nach dieser Anpassung drastisch sinkt und Anwendungen deutlich weniger ruckeln.

Ein weiterer grundlegender Baustein ist vm.dirty_ratio y vm.dirty_background_ratioDiese Werte legen fest, welcher Prozentsatz des Speichers mit geänderten Seiten belegt werden kann, bevor der Kernel diese auf die Festplatte schreibt. Zu hohe Werte können zu starken Schreibvorgängen mit erheblichen Latenzzeiten für alle Anwendungen führen, wenn der Schreibvorgang stattfindet. Eine Reduzierung dieser Prozentsätze auf Werte wie 15 bzw. 5 führt typischerweise zu einer konsistenteres und vorhersagbareres E/A-Muster.

Die Einstellung von vm.vfs_cache_pressure Dieser Wert legt fest, wie aggressiv der Kernel Inode- und Verzeichniscaches leert. Ein Standardwert von 100 führt in der Regel zu einer schnellen Cache-Leerung, während Werte um 50 die Metadaten länger speichern, wodurch die Trefferrate bei Dateivorgängen erhöht und die Leistung verbessert wird. die wahrgenommene Leistung des Dateisystems, etwas, das für Server, die Millionen kleiner Dateien verarbeiten, von entscheidender Bedeutung ist.

Für seinen Teil, vm.min_free_kbytes Um sicherzustellen, dass das System auf Speicherspitzen reagieren kann, ohne plötzliche Systemabstürze zu erleiden, sollte ein Mindestmaß an freiem Speicher reserviert werden. Eine Dimensionierung auf etwa 0,5 % bis 1 % des gesamten Arbeitsspeichers (RAM) ist in der Regel eine wirksame Sicherheitsmaßnahme, um zu verhindern, dass dem Kernel unter extremer Last der Speicherplatz ausgeht und kritische Prozesse beendet werden. Dadurch wird die Leistung verbessert. allgemeine Wirtsstabilität.

Schließlich verdient die Überverpflichtungspolitik Beachtung: Parameter wie beispielsweise vm.overcommit_memory y vm.overcommit_ratio Sie legen fest, wie viel virtueller Speicher Prozessen im Verhältnis zum verfügbaren RAM und Auslagerungsspeicher zugewiesen wird. In manchen Fällen (z. B. bei Redis oder bestimmten Datenbanken) ist eine aggressive Überbelegung zulässig, während in anderen Fällen eine konservativere Vorgehensweise bevorzugt wird, um das Risiko zu begrenzen. OOM und Situationen mit stark beeinträchtigtem GedächtnisTechniken zur Analyse und Diagnose komplexer Fälle finden Sie in der entsprechenden Literatur. Speicher-Debugging in Linux.

Erweiterte Netzwerkoptimierung: net.* und TCP/IP

Der Netzwerk-Stack ist wohl der Bereich, in dem Optimierungen in Produktionsumgebungen am deutlichsten spürbar sind. Eine einfache Änderung an Verbindungswarteschlangen oder Puffern kann den Unterschied zwischen einem Server, der bei 500 Mbit/s an seine Grenzen stößt, und einem, der … Es schöpft die Gigabit-Kapazität problemlos aus.Die Parameter unter net.core.* y net.ipv4.* In diesem Bereich sind sie Ihre besten Verbündeten.

Zunächst einmal beeinflussen Socket-Puffergrößen direkt den maximalen Durchsatz einer Verbindung, insbesondere bei hohen Latenzen oder Verbindungen mit hoher Kapazität. Anpassen net.core.rmem_max y net.core.wmem_max großzügige Werte (zehn oder hunderte Megabyte) festlegen und korrekt definieren net.ipv4.tcp_rmem y net.ipv4.tcp_wmem (Minimal-, Standard- und Maximalwert) ermöglicht es jedem Socket, die Platzbedarf zur Abfederung von Verkehrsspitzen ohne in künstliche Beschränkungen zu verfallen, die durch sehr konservative Fabrikwerte auferlegt werden.

Ein weiterer wichtiger Punkt ist die Größe der Verbindungswarteschlangen. Parameter wie beispielsweise net.core.somaxconn, net.core.netdev_max_backlog y net.ipv4.tcp_max_syn_backlog Diese Grenzwerte legen fest, wie viele ausstehende Verbindungen das System verarbeiten kann, bevor Pakete verworfen oder Handshakes abgelehnt werden. Auf stark frequentierten Webservern kann eine Erhöhung dieser Grenzwerte überlastete Warteschlangen verhindern und die Last drastisch reduzieren. Verbindungsfehler bei Spitzenlasten.

Das Verhalten von TCP-Verbindungen lässt sich zudem mit einer Vielzahl von Optionen feinabstimmen: aktivieren net.ipv4.tcp_window_scaling Um große Fenster auf Verbindungen mit hoher Bandbreite zu unterstützen, aktivieren Sie net.ipv4.tcp_sack y net.ipv4.tcp_timestamps um das Verlust- und Wiederübertragungsmanagement zu verbessern oder anzupassen net.ipv4.tcp_fin_timeout und die Verwaltung von TIME_WAIT (net.ipv4.tcp_tw_reuse, net.ipv4.tcp_max_tw_bucketsum den Ressourcenverbrauch auf Servern mit Millionen von Kurzverbindungen pro Minute.

Die Wahl des Staukontrollalgorithmus ist ebenfalls von Bedeutung. Obwohl cubic In vielen Distributionen bleibt dies der Standardwert; Änderung auf bbr in modernen Kerneln (4.9 und höher) von net.ipv4.tcp_congestion_control y net.core.default_qdisc=fq Es kann den TCP-Durchsatz in Umgebungen mit komplexen Verlusten oder Latenzen vervielfachen und in bestimmten Szenarien Verbesserungen um das 2- bis 25-Fache im Vergleich zu klassischen Konfigurationen erzielen, allerdings auf Kosten von etwas anderes Verhalten in überlasteten Netzwerken.

Wir dürfen Sicherheits- und Zuverlässigkeitsparameter wie beispielsweise nicht vergessen. net.ipv4.tcp_syncookies, die Behandlung von Weiterleitungen (net.ipv4.conf.all.accept_redirects, send_redirects) oder Filterung in Brücken (net.bridge.bridge-nf-call-iptables in Kubernetes-Umgebungen). Richtig konfiguriert ermöglichen sie den Schutz des Systems vor gängigen Angriffen (SYN-Flood, Spoofing usw.), ohne die Leistung zu beeinträchtigen. solide NetzwerkleistungEinen praktischen Leitfaden zu Regeln und Erkennung finden Sie hier: Netfilter- und Suricata-Implementierung.

Dateisystem, Deskriptoren und globale Beschränkungen: fs.* und ulimit

Auf modernen Servern ist ein zu niedriges Dateideskriptorlimit der schnellste Weg, ein System während der Spitzenzeiten zum Zusammenbruch zu bringen. Wenn ein Webserver, Reverse-Proxy oder eine Datenbank den klassischen Fehler „Zu viele offene Dateien“ meldet, liegt das in der Regel daran, dass die Kernelparameter und Benutzerlimits nicht an die tatsächliche Last angepasst wurden.

Weltweit, fs.file-max Dies legt fest, wie viele Deskriptoren der Kernel insgesamt geöffnet haben kann. Bei Anwendungen mit Tausenden gleichzeitiger Verbindungen ist es üblich, diesen Wert auf mehrere Millionen zu erhöhen, zusammen mit einer Erhöhung von fs.nr_openDies legt die maximale Anzahl an Deskriptoren pro Prozess fest. Darüber hinaus sind Anpassungen erforderlich. /etc/security/limits.conf sodass Benutzer (oder von systemd verwaltete Dienste) weiche und harte Werte, die mit der Kernelkonfiguration übereinstimmen.

Das inotify-Subsystem, das von IDEs, Webentwicklungstools und Dateiüberwachungssystemen weit verbreitet ist, wird durch Parameter wie beispielsweise … gesteuert. fs.inotify.max_user_watches y fs.inotify.max_user_instancesWenn Sie auf Fehler im Zusammenhang mit Überwachungsfunktionen oder Prozessen stoßen, die die Überwachung von Festplattenänderungen einstellen, benötigen Sie wahrscheinlich Folgendes: Erhöhen Sie diese Grenzwerte, um stille Engpässe zu vermeiden..

Ein weiteres relevantes Merkmal ist die asynchrone Ein-/Ausgabe (AIO), deren globales Maximum wie folgt definiert ist: fs.aio-max-nrBei Anwendungen, die stark auf asynchrone E/A angewiesen sind (bestimmte Datenbank-Engines, Warteschlangensysteme usw.), verhindert eine Erhöhung dieses Wertes, dass dem Kernel bei einer massiven Anforderungslast die Slots für AIO-Operationen ausgehen.

Zusätzlich zu diesen Parametern wird die Leistung des Festplattensubsystems durch Folgendes beeinflusst: E/A-Scheduler Die Konfiguration erfolgt auf jedem Blockgerät. In Systemen mit SSDs oder NVMe-Karten wird üblicherweise die Verwendung von ressourcenschonenden Schedulern wie beispielsweise empfohlen. none o mq-deadlineBei mechanischen Festplatten könnten hingegen andere Optionen sinnvoll sein, wie zum Beispiel bfq abhängig von der Art der Last. Passen Sie den Zeitplan an über /sys/block/<disco>/queue/scheduler und Optionen wie die Warteschlangenlänge feinabstimmen (nr_requests) oder die read_ahead_kb kann einen spürbaren Unterschied machen in Lese-/Schreiblatenz und DurchsatzEs ist außerdem wichtig zu berücksichtigen, welche Dateisysteme und Treiber verwendet werden; beispielsweise Artikel über NTFSplus unter Linux und andere Systeme können bei der Auslegung heterogener Lasten hilfreich sein.

Schließlich sollte nicht vergessen werden, dass diese Kernel-Beschränkungen mit Systemkonfigurationen wie denen von … einhergehen müssen. ulimit und systemd-Units, um sicherzustellen, dass Dienste die definierten zusätzlichen Ressourcen tatsächlich nutzen können und nicht blockiert werden durch Beschränkungen in den oberen Schichten.

Kernel allgemein, NUMA, CPU-Affinität und riesige Seiten

Neben Netzwerk, Speicher und Dateisystemen bietet der Kernel selbst eine Reihe von Optimierungsoptionen, die Einfluss darauf haben, wie Prozesse geplant, Arbeitslasten auf Kerne und NUMA-Knoten verteilt und der Speicher im großen Maßstab verwaltet wird. Auf modernen Rechnern mit vielen Kernen und sogar mehreren Sockeln entscheiden diese Details oft darüber, ob ein Server optimal ausgelastet ist oder ob einige Kerne voll ausgelastet sind, während andere unterausgelastet bleiben . Es lohnt sich auch, alternative Kernel wie den Liquorix-Kernel in Umgebungen zu untersuchen, in denen ein anderes Latenzprofil gewünscht ist.

Parameter wie kernel.pid_max Sie legen den maximalen Bereich von Prozess-IDs fest, die das System vergeben kann. Dies ist relevant für Knoten, auf denen eine große Anzahl von Containern oder kurzlebigen Prozessen ausgeführt wird. Anpassen der Kernel-Protokollierungsoptionen (kernel.printk) hilft, übermäßiges Rauschen in dmesg zu reduzieren und gleichzeitig kritische Ereignisse aufzuzeichnen, was sich auch indirekt auf die diagnostische Leistungsfähigkeit und Stabilität.

Bezüglich der Speichertopologie ist der Parameter kernel.numa_balancing Es steuert, in welchem ​​Umfang der Kernel Seiten automatisch zwischen NUMA-Knoten verschiebt. Die Deaktivierung in bestimmten Umgebungen ermöglicht eine explizitere Verwaltung der Prozess- und Speicheraffinität mithilfe von Tools wie beispielsweise … numactl um sicherzustellen, dass CPU- und RAM-intensive Prozesse auf demselben Knoten verbleiben, wodurch die Latenz aufgrund von FernzugriffUm das Zusammenspiel zwischen Hardware und Kernplanung besser zu verstehen, ist es auch hilfreich, Technologien wie … zu betrachten. Intel-Thread-Director.

Die riesigen Seiten (vm.nr_hugepagesSie stellen eine weitere Schlüsselkomponente in Datenbanksystemen und anderen Workloads dar, die große zusammenhängende Speicherbereiche verarbeiten. Die Reservierung einer angemessenen Anzahl von Giant Pages (2 MB oder sogar 1 GB, abhängig von der Architektur) kann den TLB-Overhead reduzieren und die Leistung von Anwendungen, die diese Seiten nutzen, deutlich verbessern. viele Operationen auf großen SpeicherblöckenDamit dies effektiv ist, muss die Kernelkonfiguration mit der Anwendung selbst abgestimmt sein, sodass diese den Speicher explizit nutzt.

Im Bereich Latenz und Scheduling gibt es Scheduler-Parameter wie zum Beispiel kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns o kernel.sched_migration_cost_nsDiese Einstellungen optimieren die Größe der jedem Prozess zugewiesenen CPU-„Chunks“ und die Aggressivität, mit der der Kernel Prozesse zwischen den Kernen verschiebt. Kleinere Werte bedeuten ein System, das leichter präemptiv arbeitet und tendenziell mehr Leistung bietet. beste Antwort für interaktive Aufgaben manchmal auf Kosten eines geringen Durchsatzes.

In Systemen, in denen der Arbeitsspeicher eine sensible Ressource darstellt, aktivieren manche Administratoren den Panikmodus im Falle eines sofortigen Fehlers (vm.panic_on_oom) und etablieren kernel.panic mit einer automatischen Neustartzeit. Diese Strategie ist zwar etwas drastisch, kann aber in Hochverfügbarkeitsumgebungen nützlich sein, in denen Ein schneller und kontrollierter Neustart ist einem hängenden und instabilen Host vorzuziehen. während Stunden.

Spezialisierte Profile: Web, Datenbanken, niedrige Latenz und Kubernetes

Anstatt eine einzige Universallösung anzuwenden, ist es effektiver, sysctl-Profile zu erstellen, die auf verschiedene Workload-Typen zugeschnitten sind: Webserver, Datenbanken, Containerplattformen oder Systeme mit geringer Latenz. Diese Einstellungen können in Dateien wie z. B. verteilt werden. 99-webserver.conf, 99-database.conf o 90-kubernetes.conf hilft eine übersichtliche und leicht versionierbare Konfiguration beibehaltenSie können auch leistungsorientierte Distributionen und Editionen wie beispielsweise … in Betracht ziehen. CachyOS Server Edition für sehr spezifische Umgebungen.

Für Webserver (Nginx, Apache, Proxys usw.) kommt es vor allem darauf an, große Mengen gleichzeitiger Verbindungen mit langen Warteschlangen und Antwortzeiten zu bewältigen. FIN_WAIT Durch Feinabstimmung, einen erweiterten Bereich temporärer Ports und sehr hohe Deskriptorlimits ist es üblich, von einigen hundert HTTP-Anfragen pro Sekunde auf mehrere tausend zu kommen, wodurch die durchschnittliche Latenz reduziert und Fehler beseitigt werden. überlastete Warteschlangen oder volle Häfen.

Auf der Datenbankseite (MySQL, PostgreSQL und ähnliche) wird Wert auf minimale Auslagerungsnutzung, Feinabstimmung des Schreibens geänderter Seiten und geeignete Einstellungen für gemeinsam genutzten Speicher und Semaphore für die Engine gelegt. Parameter wie beispielsweise kernel.shmmax, kernel.shmall, kernel.sem und die Konfiguration für riesige Seiten macht einen Unterschied in Bezug auf Transaktionen pro Sekunde und AntwortzeitDadurch wird die Leistung in vielen Szenarien im Vergleich zu den Standardwerten um das Zwei- bis Dreifache gesteigert.

Für Anwendungen mit extrem niedriger Latenz (Handel, Online-Spiele, Echtzeitverarbeitung) werden noch spezifischere Einstellungen hinzugefügt: net.ipv4.tcp_low_latencyDeaktivierung des Sanftanlaufs nach Inaktivität, Verwendung von tcp_fastopen, ausgelastete Umfrageparameter (net.core.busy_poll, busy_read) und in vielen Fällen die Deaktivierung transparenter Huge Pages durch /sys/kernel/mm/transparent_hugepage/enabledAll dies zielt darauf ab, die Verarbeitungswarteschlange und Latenz erreichen Spitzenwerte in den hohen Perzentilenund erzielte spektakuläre Verbesserungen bei P99.

In Container- und Kubernetes-Umgebungen sind der Netzwerk-Stack und das Verbindungs-Tracking besonders stark beansprucht. Parameter wie beispielsweise net.ipv4.ip_forward, net.bridge.bridge-nf-call-iptables, net.netfilter.nf_conntrack_maxDie Verwendung reservierter Ports für NodePort oder die Anpassung von ARP-Tabellen ist üblich auf Knoten, die Hunderte oder Tausende von Pods verwalten. Eine korrekte Konfiguration beugt Problemen vor. Abgebrochene Verbindungen, Timeouts oder Tabellenüberlastung bei Conntrack.

Abgesehen von diesen spezifischen Profilen entscheiden sich einige Organisationen für ein leistungsorientiertes Archiv mit erhöhter Sicherheit, das große Netzwerkpuffer und reduzierte Swappiness mit Maßnahmen wie den folgenden kombiniert: tcp_syncookies oder die Blockierung gefährlicher Weiterleitungen. Ziel ist es, Folgendes zu erreichen: Ausgewogenheit zwischen aggressiver Leistung und angemessener Härtung.

Kernel-Profiling- und Überwachungstools

Den Kernel zu verändern, ohne vorher Messungen durchzuführen, ist wie blind an einem Audiomixer zu arbeiten. Linux bietet eine Vielzahl von Werkzeugen, um zu verstehen, was das System tatsächlich tut – von einfachen Zählern bis hin zu detaillierten Protokollen von Kernelfunktionen. So können Sie Konfigurationsänderungen mit messbaren Auswirkungen korrelieren.

Zu den alltäglichen Gebrauchsgegenständen gehören vmstat, iostat, sar, ss, slabtop, htop o pidstatdie schnell Informationen über Prozesse, CPU-Auslastung, E/A, Socket- und Cache-Nutzung liefern. Kombiniert mit Systemprotokollen und Metriken, die an Prometheus, Grafana oder collectd exportiert werden, und mit Ressourcen wie Erweiterter Systemmonitor für LinuxSie vermitteln ein recht vollständiges Bild davon, wie sich der Host vor und nach jeder Abstimmung verhält.

Um genauer darauf einzugehen, gibt es beispielsweise folgende Tools: perf Sie ermöglichen die Profilierung der CPU-Auslastung auf Funktionsebene, sowohl auf Benutzer- als auch auf Kernelebene, protokollieren Ereignisse für einige Sekunden oder Minuten und stellen anschließend einen interaktiven Bericht bereit. perf stat, perf record y perf report können Sie sehen, wo tatsächlich CPU-Zeit verbraucht wird und welcher Anteil dem Kern entsprichtzum Beispiel die Identifizierung eines Unterbrechungssturms oder eines schlecht eingestellten Zeitplaners.

Falls Sie noch detailliertere Informationen benötigen, ftrace Das Tracing-Subsystem des Kernels ermöglicht die Aktivierung spezifischer Tracer (z. B. des Funktionstracers) und die Untersuchung der Aufrufe in Echtzeit oder im Nachhinein. Dazu wird der entsprechende Tracer aktiviert und dessen Inhalt analysiert. /sys/kernel/debug/tracing/trace Es offenbart dir Hotspots innerhalb des Kernels selbstDies ist sehr nützlich, wenn Kennzahlen auf hoher Ebene nicht ausreichen.

Parallel dazu empfiehlt es sich, automatisierte Überwachungsskripte einzusetzen, die regelmäßig wichtige Daten (Netzwerkstatistiken, Speicherauslastung, Anzahl offener Dateideskriptoren usw.) in rotierende Protokolldateien schreiben. Sobald bestimmte Schwellenwerte erreicht sind (z. B. eine festgelegte Anzahl offener Dateideskriptoren überschritten wird), können diese Skripte Warnmeldungen per E-Mail oder über andere Kanäle generieren und so dazu beitragen, gefährliche Entwicklungen zu erkennen, bevor ein Problem eskaliert.

Schließlich kommen in längeren Stresstestphasen (24 Stunden oder länger) Hilfsmittel wie … zum Einsatz. stress-ng kombiniert mit der kontinuierlichen Erfassung von Kennzahlen (über vmstat, iostat, sar) ermöglichen es Ihnen, die Stabilität des Systems mit der neuen Kernel-Konfiguration zu beurteilen und zu überprüfen, ob es zu OOM-Ereignissen, Abstürzen, unerwarteten Neustarts oder fortschreitenden Leistungsverschlechterungen unter anhaltender Last kommt.

Die Optimierung des Linux-Kernels mit sysctl und anderen Mechanismen ist keine einmalige Aufgabe, sondern ein iterativer Prozess, der die Messung von Ergebnissen, die Anpassung von Parametern und die sorgfältige Dokumentation aller Schritte umfasst. Mit einer klaren Methodik, spezifischen Profilen für jede Arbeitslast, einer leistungsstarken Suite von Profiling-Tools und strikter Änderungskontrolle lassen sich Server realisieren, die ihre Hardware optimal ausnutzen und im Vergleich zur Standardkonfiguration einen höheren Durchsatz, geringere Latenz und deutlich höhere Stabilität bieten.

In Verbindung stehender Artikel:

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