RHEL Systemleistung optimieren: Tuning mit tuned, nice und renice

Einführung

In diesem Lab lernen Sie, wie Sie die Leistung eines RHEL-Systems mit tuned optimieren und Prozessprioritäten mit nice und renice verwalten. Sie beginnen mit der Überprüfung der tuned-Installation und der Auflistung der verfügbaren Profile, um dann zu beobachten, wie sich das Ändern der tuned-Profile auf Systemparameter auswirkt.

Das Lab führt Sie durch das Starten und Überwachen von CPU-intensiven Prozessen, gefolgt von der Anpassung ihrer Prioritäten mit nice und renice, um deren Auswirkungen auf die Ressourcenallokation zu verstehen. Abschließend lernen Sie, wie Sie laufende Prozesse bereinigen, um ein umfassendes Verständnis der Performance-Optimierung unter RHEL zu gewährleisten.

tuned-Status überprüfen und verfügbare Profile auflisten

In diesem Schritt lernen Sie, wie Sie den Status des tuned-Daemons überprüfen und verfügbare Tuning-Profile auf Ihrem RHEL-System auflisten. tuned ist ein dynamischer, adaptiver System-Tuning-Daemon, der Systemeinstellungen optimiert, um die Leistung für bestimmte Workloads zu optimieren. Er verwendet Tuning-Profile, um eine Reihe von systemweiten Einstellungen anzuwenden.

Überprüfen Sie, ob der tuned-Daemon läuft.
In dieser Containerumgebung überprüfen wir, ob der tuned-Daemon läuft, indem wir nach seinem Prozess suchen. Wir können seine Funktionalität auch überprüfen, indem wir prüfen, ob er auf Befehle reagiert.

Überprüfen Sie zuerst, ob der tuned-Prozess läuft:
```
pgrep tuned
```
Wenn tuned läuft, gibt dieser Befehl seine Prozess-ID (PID) zurück. Wenn keine PID zurückgegeben wird, können Sie den Daemon manuell starten:
```
sudo /usr/sbin/tuned &
```
Überprüfen Sie dann, ob er läuft:
```
pgrep tuned
```
Sie sollten eine Ausgabe ähnlich der folgenden sehen:
```
739
```
(Hinweis: Der PID-Wert in Ihrer Ausgabe variiert.)

Darüber hinaus können Sie überprüfen, ob tuned funktionsfähig ist, indem Sie prüfen, ob er auf Statusabfragen reagiert:
```
sudo tuned-adm active
```
Dies sollte das aktuell aktive Profil ohne Fehler zurückgeben.

Listen Sie die verfügbaren Tuning-Profile auf und identifizieren Sie das aktive Profil.
Der Befehl tuned-adm list zeigt alle verfügbaren Tuning-Profile an und hebt das aktuell aktive Profil hervor.

sudo tuned-adm list

Sie werden nach Ihrem Passwort gefragt. Beachten Sie das Current active profile in der Ausgabe.

Available profiles:
- accelerator-performance     - Throughput performance based tuning with disabled higher latency STOP states
- aws                         - Optimize for aws ec2 instances
- balanced                    - General non-specialized tuned profile
- balanced-battery            - Balanced profile biased towards power savings changes for battery
- desktop                     - Optimize for the desktop use-case
- hpc-compute                 - Optimize for HPC compute workloads
- intel-sst                   - Configure for Intel Speed Select Base Frequency
- latency-performance         - Optimize for deterministic performance at the cost of increased power consumption
- network-latency             - Optimize for deterministic performance at the cost of increased power consumption, focused on low latency network performance
- network-throughput          - Optimize for streaming network throughput, generally only necessary on older CPUs or 40G+ networks
- optimize-serial-console     - Optimize for serial console use.
- powersave                   - Optimize for low power consumption
- throughput-performance      - Broadly applicable tuning that provides excellent performance across a variety of common server workloads
- virtual-guest               - Optimize for running inside a virtual guest
- virtual-host                - Optimize for running KVM guests
Current active profile: virtual-guest

Überprüfen Sie die Konfiguration des virtual-guest-Profils.
Das virtual-guest-Profil ist oft die Standardeinstellung für virtuelle Maschinen. Sie können seine Konfigurationsdatei untersuchen, um zu verstehen, welche Einstellungen es anwendet.

cat /usr/lib/tuned/virtual-guest/tuned.conf

Dieser Befehl zeigt die tuned-Konfiguration für das virtual-guest-Profil, einschließlich der Parameter, die es von anderen Profilen erbt.

#
## tuned configuration
#

[main]
summary=Optimize for running inside a virtual guest
include=throughput-performance

[vm]
## If a workload mostly uses anonymous memory and it hits this limit, the entire
## working set is buffered for I/O, and any more write buffering would require
## swapping, so it's time to throttle writes until I/O can catch up.  Workloads
## that mostly use file mappings may be able to use even higher values.
#
## The generator of dirty data starts writeback at this percentage (system default
## is 20%)
dirty_ratio = 30

[sysctl]
## Filesystem I/O is usually much more efficient than swapping, so try to keep
## swapping low.  It's usually safe to go even lower than this on systems with
## server-grade storage.
vm.swappiness = 30

Überprüfen Sie, ob der Parameter vm.dirty_background_ratio angewendet wird.
Das virtual-guest-Profil enthält throughput-performance. Überprüfen wir einen Parameter, den throughput-performance typischerweise setzt, wie z. B. vm.dirty_background_ratio. Dieser Parameter steuert, wann das System im Hintergrund beginnt, Dirty Pages auf die Festplatte zu schreiben.
```
sysctl vm.dirty_background_ratio
```
Die Ausgabe zeigt den aktuellen Wert dieses Kernel-Parameters.
```
vm.dirty_background_ratio = 10
```

tuned-Profil ändern und Änderungen der Systemparameter beobachten

In diesem Schritt lernen Sie, wie Sie das aktive tuned-Profil ändern und die unmittelbaren Auswirkungen auf Systemparameter beobachten. Das Ändern eines tuned-Profils ermöglicht es Ihnen, schnell eine Reihe von Leistungsoptimierungen anzuwenden, die auf verschiedene Workloads zugeschnitten sind, wie z. B. durchsatzintensive Aufgaben oder Energiesparen.

Ändern Sie das aktuell aktive Tuning-Profil in throughput-performance.
Das Profil throughput-performance ist für Systeme konzipiert, die einen hohen Durchsatz erfordern, oft unter Inkaufnahme einer gewissen Latenz. Es optimiert typischerweise für Festplatten-I/O und Netzwerkleistung. Verwenden Sie den Befehl tuned-adm profile, um die Profile zu wechseln.
```
sudo tuned-adm profile throughput-performance
```
Sie werden nach Ihrem Passwort gefragt.
```
$ sudo tuned-adm profile throughput-performance
[sudo] password for user:
```
Bestätigen Sie das neue aktive Profil.
Nach dem Ändern des Profils ist es gute Praxis, zu überprüfen, ob das neue Profil tatsächlich aktiv ist. Sie können dies mit tuned-adm active tun.
```
sudo tuned-adm active
```
Die Ausgabe sollte jetzt throughput-performance als aktives Profil anzeigen.
```
Current active profile: throughput-performance
```
Überprüfen Sie, ob sich die Parameter vm.dirty_ratio und vm.swappiness geändert haben.
Das Profil throughput-performance ändert Kernel-Parameter, die sich auf die Speicherverwaltung beziehen, wie z. B. vm.dirty_ratio und vm.swappiness. Obwohl das Profil virtual-guest von throughput-performance erbt, wendet das direkte Umschalten auf das Profil throughput-performance die Basiswerte ohne die virtual-guest-spezifischen Modifikationen an.
- vm.dirty_ratio: Dieser Parameter definiert den maximalen Prozentsatz des Systemspeichers, der mit Dirty Pages (Seiten, die geändert, aber noch nicht auf die Festplatte geschrieben wurden) gefüllt werden kann, bevor das System beginnt, sie auf die Festplatte zu schreiben. Ein höherer Wert kann den Durchsatz verbessern, indem mehr Daten im Speicher gepuffert werden können.
- vm.swappiness: Dieser Parameter steuert, wie aggressiv der Kernel anonymen Speicher (Anwendungsdaten) aus dem RAM in den Swap-Bereich auslagert. Ein niedrigerer Wert bedeutet, dass der Kernel versuchen wird, mehr Anwendungsdaten im RAM zu halten, was im Allgemeinen besser für die Leistung ist.
Überprüfen wir ihre aktuellen Werte mit sysctl.
```
sysctl vm.dirty_ratio
sysctl vm.swappiness
```
Sie sollten feststellen, dass sich die Werte von den Einstellungen des Profils virtual-guest (dirty_ratio = 30, vm.swappiness = 30) auf die Basiswerte des Profils throughput-performance geändert haben:
```
vm.dirty_ratio = 40
vm.swappiness = 10
```
(Hinweis: Diese Werte spiegeln die Basis-throughput-performance-Optimierungen ohne die virtual-guest-spezifischen Modifikationen wider.)

CPU-intensive Prozesse unter RHEL starten und überwachen

In diesem Schritt lernen Sie, wie Sie CPU-intensive Prozesse starten und ihre Ressourcenauslastung überwachen. Dies ist entscheidend, um zu verstehen, wie Prozesse Systemressourcen verbrauchen und wie Engpässe identifiziert werden können. Wir verwenden den Befehl sha1sum /dev/zero, der kontinuierlich die SHA1-Prüfsumme eines endlosen Datenstroms von Nullen berechnet und somit effektiv CPU-Zyklen verbraucht.

Wichtig: Diese Übung verwendet Befehle, die endlose Prüfsummen auf einer Gerätedatei ausführen und absichtlich erhebliche CPU-Ressourcen verbrauchen. Sie müssen alle Übungsprozesse beenden, bevor Sie diese Übung verlassen oder zum nächsten Lab wechseln.

Ermitteln Sie die Anzahl der CPU-Kerne auf Ihrem System.
Das Verständnis der Anzahl der CPU-Kerne hilft Ihnen bei der Entscheidung, wie viele CPU-intensive Prozesse ausgeführt werden sollen, um das System vollständig auszulasten. Sie finden diese Informationen in /proc/cpuinfo.
```
grep -c '^processor' /proc/cpuinfo
```
Dieser Befehl zählt die Anzahl der Zeilen, die mit processor beginnen, was der Anzahl der logischen CPU-Kerne (oder virtuellen Prozessoren) entspricht.
```
2
```
(Hinweis: Ihre Ausgabe zeigt möglicherweise eine andere Anzahl von Kernen, abhängig von der Systemkonfiguration.)
Starten Sie zwei Instanzen des Befehls sha1sum /dev/zero & für jeden CPU-Kern.
Um ein stark ausgelastetes System zu simulieren, starten wir mehrere Instanzen von sha1sum /dev/zero &. Das & am Ende des Befehls führt den Prozess im Hintergrund aus, sodass Sie das Terminal weiterhin verwenden können. Wenn Sie beispielsweise 2 CPU-Kerne haben, würden Sie 4 Instanzen starten (2 Instanzen/Kern * 2 Kerne).
```
for i in $(seq 1 $(grep -c '^processor' /proc/cpuinfo | awk '{print $1 * 2}')); do sha1sum /dev/zero & done
```
Dieser Befehl berechnet dynamisch die Anzahl der zu startenden Prozesse basierend auf Ihrer CPU-Kernanzahl.
```
[1] 1234
[2] 1235
[3] 1236
[4] 1237
```
(Hinweis: Die PID-Werte in Ihrer Ausgabe variieren vom Beispiel.)
Überprüfen Sie, ob die Hintergrundjobs laufen.
Der Befehl jobs listet alle Prozesse auf, die derzeit im Hintergrund von Ihrer Shell-Sitzung ausgeführt werden.
```
jobs
```
Sie sollten eine Liste der sha1sum-Prozesse sehen, die Sie gerade gestartet haben.
```
[1]   Running                 sha1sum /dev/zero &
[2]   Running                 sha1sum /dev/zero &
[3]   Running                 sha1sum /dev/zero &
[4]-  Running                 sha1sum /dev/zero &
```
Verwenden Sie die Befehle ps und pgrep, um den Prozentsatz der CPU-Auslastung für jeden sha1sum-Prozess anzuzeigen.
Der Befehl ps meldet eine Momentaufnahme der aktuellen Prozesse. Wir kombinieren ihn mit pgrep, um nach sha1sum-Prozessen zu filtern.
- ps -o pid,pcpu,nice,comm: Dies gibt das Ausgabeformat an: Prozess-ID (pid), Prozentsatz der CPU-Auslastung (pcpu), nice-Wert (nice) und Befehlsname (comm).
- $(pgrep sha1sum): Diese Befehlssubstitution findet die PIDs aller Prozesse mit dem Namen sha1sum und übergibt sie als Argumente an ps.
```
ps -o pid,pcpu,nice,comm $(pgrep sha1sum)
```
Sie sollten sehen, dass jeder sha1sum-Prozess einen signifikanten Prozentsatz der CPU verbraucht.
```
    PID %CPU  NI COMMAND
   5248 48.8   0 sha1sum
   5249 48.7   0 sha1sum
   5250 48.8   0 sha1sum
   5251 48.8   0 sha1sum
```
(Hinweis: Die %CPU-Werte können schwanken, sollten aber hoch sein, was auf eine hohe CPU-Auslastung hindeutet. Die Spalte NI zeigt den Nice-Wert.)
Beenden Sie alle laufenden sha1sum-Prozesse und überprüfen Sie, ob keine mehr vorhanden sind.
Es ist entscheidend, diese CPU-intensiven Prozesse zu bereinigen, bevor Sie fortfahren. Der Befehl pkill beendet Prozesse basierend auf ihrem Namen.
```
pkill sha1sum
```
Überprüfen Sie nun, ob keine sha1sum-Jobs mehr im Hintergrund laufen.
```
jobs
```
Die Ausgabe sollte leer sein oder anzeigen, dass alle Jobs beendet wurden.
```
[1]   Terminated              sha1sum /dev/zero
[2]   Terminated              sha1sum /dev/zero
[3]   Terminated              sha1sum /dev/zero
[4]-  Terminated              sha1sum /dev/zero
```
(Hinweis: Möglicherweise sehen Sie "Terminated"-Meldungen, was erwartet wird, da die Prozesse gestoppt werden.)

Prozesspriorität mit nice und renice unter RHEL anpassen

In diesem Schritt lernen Sie, wie Sie die Scheduling-Priorität von Prozessen mithilfe der Befehle nice und renice beeinflussen können. Der nice-Wert (auch als Niceness bekannt) eines Prozesses gibt seine Priorität für den Linux-Scheduler an. Ein niedrigerer nice-Wert (negativer) bedeutet eine höhere Priorität, während ein höherer nice-Wert (positiver) eine niedrigere Priorität bedeutet. Der Bereich für nice-Werte liegt typischerweise zwischen -20 (höchste Priorität) und 19 (niedrigste Priorität), wobei 0 der Standardwert ist.

Starten Sie mehrere Instanzen von sha1sum /dev/zero & und starten Sie dann eine zusätzliche Instanz mit einem nice-Level von 10.
Wir starten mehrere sha1sum-Prozesse, um ein ausgelastetes System zu simulieren. Dann starten wir einen mit einer absichtlich niedrigeren Priorität (höherer nice-Wert), um die Auswirkungen zu beobachten.

Starten Sie zuerst drei reguläre Instanzen (passen Sie sie bei Bedarf an Ihre CPU-Kernanzahl an, aber mindestens so viele wie virtuelle Prozessoren, um Konflikte zu erzeugen):
```
for i in {1..3}; do sha1sum /dev/zero & done
```
Starten Sie als Nächstes die vierte Instanz mit einem nice-Level von 10. Dieser Prozess hat eine niedrigere Priorität im Vergleich zu den anderen.
```
nice -n 10 sha1sum /dev/zero &
```
Sie sehen eine ähnliche Ausgabe wie diese, die die PIDs der Hintergrundprozesse anzeigt:
```
[1] 5443
[2] 5444
[3] 5445
[4] 5446
```
(Hinweis: Die PID-Werte in Ihrer Ausgabe variieren.)
Verwenden Sie die Befehle ps und pgrep, um die PID, den Prozentsatz der CPU-Auslastung, den nice-Wert und den Ausführungsnamen für jeden Prozess anzuzeigen.
Beobachten Sie die Spalten %CPU und NI. Die Instanz mit dem nice-Wert von 10 sollte einen geringeren Prozentsatz der CPU-Auslastung anzeigen als die anderen Instanzen, da der Scheduler ihr weniger CPU-Zeit gibt.
```
ps -o pid,pcpu,nice,comm $(pgrep sha1sum)
```
Suchen Sie nach dem Prozess mit dem NI-Wert 10. Sein %CPU sollte deutlich niedriger sein als die anderen.
```
    PID %CPU  NI COMMAND
   5443 56.8   0 sha1sum
   5444 58.0   0 sha1sum
   5445 56.5   0 sha1sum
   5446  6.7  10 sha1sum
```
(Hinweis: Die genauen %CPU-Werte variieren je nach Systemauslastung und Kernanzahl, aber der Prozess mit nice 10 sollte einen geringeren Anteil haben.)
Verwenden Sie den Befehl sudo renice, um den nice-Level eines der regulären Prozesse auf 5 zu ändern.
Mit dem Befehl renice können Sie den nice-Wert eines bereits laufenden Prozesses ändern. Wir demonstrieren dies, indem wir einen der regulären Prozesse (nice-Wert 0) in einen nice-Wert von 5 ändern.

Ermitteln Sie zunächst die PID eines der sha1sum-Prozesse, der einen nice-Wert von 0 hat, aus der Ausgabe des vorherigen ps-Befehls. Verwenden wir den ersten aus dem obigen Beispiel (PID 5443).
```
sudo renice -n 5 <PID_of_regular_process>
```
Ersetzen Sie <PID_of_regular_process> durch die tatsächliche PID, die Sie identifiziert haben. Zum Beispiel:
```
sudo renice -n 5 5443
```
Sie sollten eine Ausgabe sehen, die die Prioritätsänderung bestätigt:
```
5443 (process ID) old priority 0, new priority 5
```
Wiederholen Sie die Befehle ps und pgrep, um den CPU-Prozentsatz und den nice-Level anzuzeigen.
Beobachten Sie die Änderung der CPU-Auslastung für den Prozess, dessen nice-Wert Sie geändert haben. Der Prozess mit dem nice-Wert 5 sollte jetzt eine etwas geringere CPU-Auslastung im Vergleich zu den Prozessen mit dem nice-Wert 0 aufweisen, aber höher als der Prozess mit dem nice-Wert 10.
```
ps -o pid,pcpu,nice,comm $(pgrep sha1sum)
```
Sie sollten sehen, dass der NI-Wert für den geänderten Prozess jetzt 5 ist und seine CPU-Auslastung sein neues Prioritätsniveau widerspiegelt.
```
    PID %CPU  NI COMMAND
   5443 55.4   5 sha1sum
   5444 67.2   0 sha1sum
   5445 67.1   0 sha1sum
   5446  7.5  10 sha1sum
```
(Hinweis: Die genauen %CPU-Werte variieren, aber Sie sollten beobachten, dass Prozesse mit niedrigeren nice-Werten (höherer Priorität) mehr CPU-Zeit erhalten.)

Laufende Prozesse bereinigen

In diesem letzten Schritt stellen Sie sicher, dass alle im Lab gestarteten Hintergrundprozesse ordnungsgemäß beendet werden. Dies ist ein kritischer Bereinigungsschritt, um eine unbeabsichtigte Ressourcenauslastung zu verhindern und sicherzustellen, dass die Lab-Umgebung für die zukünftige Nutzung zurückgesetzt wird.

Verwenden Sie den Befehl pkill, um alle laufenden Prozesse mit dem Namensmuster sha1sum zu beenden.
Der Befehl pkill ist eine effiziente Möglichkeit, ein Signal (standardmäßig SIGTERM) an Prozesse basierend auf ihrem Namen zu senden. Dadurch werden alle sha1sum-Prozesse gestoppt, die Sie in den vorherigen Schritten gestartet haben.
```
pkill sha1sum
```
Möglicherweise sehen Sie Meldungen, die anzeigen, dass Prozesse beendet wurden.
```
[3]-  Terminated              sha1sum /dev/zero
[2]-  Terminated              sha1sum /dev/zero
[4]+  Terminated              nice -n 10 sha1sum /dev/zero
[1]+  Terminated              sha1sum /dev/zero
```
Überprüfen Sie, ob keine sha1sum-Prozesse mehr laufen.
Sie können pgrep verwenden, um zu überprüfen, ob noch sha1sum-Prozesse aktiv sind. Wenn pgrep keine Ausgabe zurückgibt, bedeutet dies, dass keine solchen Prozesse ausgeführt werden.
```
pgrep sha1sum
```
Dieser Befehl sollte keine Ausgabe zurückgeben, was darauf hindeutet, dass alle sha1sum-Prozesse erfolgreich beendet wurden.
```
$ pgrep sha1sum
$
```

Zusammenfassung

In diesem Lab haben wir gelernt, wie man tuned für die Systemleistungsoptimierung unter RHEL verwaltet und nutzt. Wir begannen mit der Überprüfung der Installation und des Status des tuned-Dienstes und der Auflistung der verfügbaren Tuning-Profile, wobei wir verstanden, dass tuned die Systemeinstellungen mithilfe dieser Profile dynamisch an spezifische Workloads anpasst. Anschließend übten wir uns im Einloggen in eine simulierte servera-Umgebung per SSH als Benutzer labex und bestätigten die Installation des tuned-Pakets mit dnf list tuned.

Das Lab führte uns weiter durch das Ändern von tuned-Profilen, um deren Auswirkungen auf Systemparameter zu beobachten, und demonstrierte, wie verschiedene Profile das Systemverhalten verändern können. Wir sammelten auch praktische Erfahrungen beim Starten und Überwachen von CPU-intensiven Prozessen, was für die Identifizierung von Leistungsengpässen von entscheidender Bedeutung ist. Schließlich lernten wir, Prozessprioritäten mithilfe der Befehle nice und renice anzupassen, um die Ressourcenzuweisung effektiv zu verwalten, und schlossen mit der Bereinigung laufender Prozesse ab, um das System in seinen ursprünglichen Zustand zurückzusetzen.

Systemleistung in RHEL optimieren