Plaudern wir heute ein bisschen über Performance und die Tools. Wie bekommt man eine Übersicht wie es meinem System denn so geht. Seit Urzeiten wird in Unix-Systemen und dazu zählt auch Linux, die beiden alten Grundsätze angewandt:
- Regel Alles ist ein File.
Nun der Satz hat mit Performance an und für sich überhaupt nichts am Hut, bis man zum Memory kommt. Das „File“ Ram wird als Datei behandelt. Die Tastatur ist ein File, man kann davon lesen. Die TCP-Verbindung ist ein File man kann schreiben und lesen. Das Bildschirm „File“ kann man beschreiben.
Und damit ist auch schon klar, welches Interface immer besonderer Betrachtung würdig ist. I/O ist das A und O im diesem Bereich. - Regel: Alles wird so schnell erledigt wie es geht.
Wenn ein Programm etwas anfordert bekommt es alles was der Kern hat. Z.B. CPU-Zeit. Gleichzeitig wird es bestraft. 100% CPU sind 100 Strafpunkte. Je weniger Strafpunkte ich habe desto eher bekomme ich CPU-Zeit. Detto beim Speicher. Jemehr Speicher ich will, desto früher geht er in den Page-Out Bereich. Natürlich gibt es dann noch Aktionen die dem widersprechen.
Performance-Messung.
Wenn man diese beiden Regeln beherzigt, dann wird einem etn paar Sachen klarer. Nun schauen wir uns ein Paar Tools an. Ich lasse alle Tools die unter einer grafischen Oberfläche außer acht und stelle als erstes Tool
top
vor. Top wird mit jedem Debiansystem mitinstalliert und zeigt die aktuellen Auslastungswerte an. Eine Historie gibt es nicht und somit auch keine nachträgliche Auswertung. Man beobactet das System im jeweiligen Zustand.
Ihr bekommt so ein Bild, dass sich in kurzer Zeit jeweils angepasst wird. mit dem Buchstaben h bekommt ihr eine Hilfe, was ihr einstellen könnt. Ich möchte mich jetzt auf den oberen Teil konzentieren und mit load beginnen.
Der load gibt die Anzahl der Prozesse die auf eine CPU warten an. Jeweils den Durchschnitt der letzten Minute, der letzten 5 Minuten und der letzten 15 Minuten. von meinen 253 Prozessen, wollten im Durchschnitt mehr als 2 immer etwas tun.
Das sagt nicht aus, dass meine CPU ausgelastet sind, sondern das Taskwechsel dafür anstehen.
Im nächsten Kasten sind besonders die Werte us sy und wa von Interesse. us zeigt wieviel cpu-Zeit von Anwenderprozessen verbraucht wird. sy ist der Wert des Kern und der loadable Module. Die loadable Module sind jene Kernkomponenten die beim boot zum Kern dazugeladen werden. (Viedo, Audio, Netzwerk Festplatten u.v.m) Das Programm „lsmod“ zeigt euch diese an.
Für die Performance könnte der wa-Wert ausschlaggebend sein. WA ist der Wert für „wait for E/A“ also wieviel Prozent der CPU für Inpu/Output verwendet wird. In meinem Fall gehen ca. 6% auf solche Operationen. Ein Indiz dass mein armer alter Lappi etwas zu tun hat.
Die nächsten beiden Felder HI und SI sind die Interrupt Indikatoren in % der CPU-Zeit. HI für Hardware-Interrupt, SI für Software Interrupt. Wenn ein Iterrupt auftritt dann muss der Kern sofort reagieren, und unterbricht das laufende Programm und händelt den Interrupt. Dazu kommt es zu einem Taskwechsel, und jede Menge von Aktionen laufen dabei ab. (z.B. Registerettung, Recovery/Wiederholung etc. ) Nehmen wir einen Plattenfehler beim Schreiben. Dann wird der Block als bad-gekennzeichnet, ein Reserveblock gesucht, der Block als gültig gekennzeichnet, die Verkettung im Filesystem durchgeführt und der Schreibauftrag auf den Block wiederholt.
Ein hoher HI-Wert deutet darauf hin, das die CPU viel Zeit für Hardware-Interrupt verbraucht. Ggf kann ein Hardwaredefekt vorliegen. Normale Werte sind für beide Felder gegen 0.
Der letzte Block zeigt uns den Speicherverbrauch real und im Swap. Den Swap schauen wir und näher an. Was an realen Speicher z.Z nicht gebraucht, wird ls Buffer vorgemerkt und für Plattencache, Programmchache verwendet.
vmstat
isr das zweite Programm das mitgeliefert wird. vmstat kann mit 2 Paparameter gestartet werden. der erste gibt die Zeitdauer zwischen 2 Ausgabezeilen und der Zweite die Anzahl der Wiederholungen. Also vmstat 6 10 liefert alle 6 Sekunden 10 mal Messungen über die Auslastung.
Wir sehen wieder unsere werte nur diesmal in einer liste und wir können diese auch speichern z.B vmstat x y >/tmp/ausgabe.csv
Dafür kommen ein paar Spalten hinzu. Swap liefert wieviele Prozesse/Blöcke in den Swap-Bereich geschrieben bzw gelesen werden und io liefert die Blöcke für Ein- und Ausgabeaktivitäten.
SWAP
Der heilige Gral oder wie groß darf er sein? Stellen wir einmal die Frage was ist der SWAP und wofür brauche ich ihn.
Der Swap ist jener Bereich auf der Platte in dem Programme/-teile ausgelagert werden dürfen, wenn sie im realen Speicher keinen Platz mehr haben. Wenn mein Programm 100 MB groß ist, ich aber nur mehr 50MB freien Speicher habe, werden vom Kern andere 50 MB auf die Platte geschrieben und mein Programm kann geladen werden. Das bezeichnet man als swapout der umgekerteFall das swapin erfolgt dann wenn diese wieder benötigt werden, dafür werden dann andere Teile ausgelagert.
Swap in oder out ist ein eindeutiges Indiz für eine etwas schlechtere Performance. Jeder Block ruft einen Vorgang auf der HDD/SSD hervor und der dauert.
der Vorteil ist auch wenn ich viele Programme gestartet habe, geht mein Speicher nicht aus.
Einige Stimmen sagen, brauche ich nicht, ich habe 64 GB Ram und swappe nie. Du Glücklicher …. Aber und hier kommt das Aber. Ruhezustand, Hibernation oder „Suspend to Disk“ speichert den Zustand des Rechners wohin? Richtig in den SWAP
Also seid nicht gierig und gönnt eurem PC die Speichgröße * 1,5 als SWAP.
Und wenn wir schon dabei sind, ihr wollt ja wieder aufwachen. Der SWAP sollte entweder in einer eigenen Partition auf einer Platte die schon beim boot erreichbar ist oder im Root-Filesystem liegen.
Viel Spass ab jetzt bei den Suspend-Funktionen. Den Swap kann man mit dem Programm „free“ überprüfen,
CPU-Last und Performance
Sagen wir ich habe 2 CPU in meinen Rechner und ich starte ein Programm das wie der Teufel rechnet. Merke ich etwas davon? Natürlich nicht die 2 CPU rekelt sich in der Gegend. Ich starte das Programm ein zweites mal. Natürlich merke ich ….. Nichts.
Ein 3, und ein 4. mal. Optisch merke ich immer noch nichts. Jedes dieser Programme wird bestraft, weil es seinen Timeslot voll ausnützt. Die Programme werden jedes für sich zwar länger dauern, aber Programme die Zeit abgeben werden dafür belohnt und bekommen mehr Slotanteile und Timeslices. Für dich schaut es so aus, als würde sich nichts ändern.
Steuern kann ich es von der shell aus mit dem nice/renice Kommando. Das Kommando „man renice“ gibt eine Übersicht über die Befehle.
Du willst es ausprobieren? Dann müssen wir etwas programmieren.
#include <stdio.h>
#include <errno.h>
int main() {
long i=0;
int a=0;
while ( a != 10 ) {
while (i != 10000000000) {
i++;
}
printf("Durchlauf %d \n",a);
a++;
}
}
diese Datei müssen wir speichern unter „jipi.c“ Danach tippen wir den Befehl
make jipi
und wie haben ein Programm. ein Start mittels „./jipi &“ wird dieses Programm im Hintergrund laufen lassen. top zeigt es uns an mit entsprechend hoher Auslastung. Wenn ich jetzt das Programm mehrmals starte wird sich die CPU Auslastung um jeweils eine CPU vergroßern. Bei 2 CPU muss ich das Programm 2 c starten bei 4 CPU 4 mal.
Merkt ihr an der Performance etwas?
Bei voller Auslastung passiert sehr wenig, was ihr merkt.
Wir können jetzt den Durchlauf mit der Ergänzung „time ./jipi &“ starten. Nach dem 10. Durchlauf bekommt ihr eine Aufstellung über Gesamt-Zeit, Kern- und User-zeit die das Programm verbraucht hat. Die Gesamt-Zeit wird bis zur Nutzung aller CPU nicht wesentlich verändern danach steigt sie wesentlich an. Also bei 2 CPU wird sich nach dem 3. Start die Durchlaufzeit um 33% erhöhen. Bei 4 Programmen verdoppelt sich die Laufzeit.
Ein Frontend Programm hat aber keine wesentliche Einschränkungen. Diese Programme, die brav ihren Timeslot abgegeben haben, werden belohnt und bekommen früher wieder eine CPU zugewiesen.
Wann der Kern nicht mehr mit den Taskwechsel und -verwaltung nicht mehr nachkommt, habe ich in der Praxis noch nicht erlebt.
Der ewige Engpass, der Speicher
Ja das ist er. Jedes moderne Programm benutzt Shared-Libaries. Dies sind Dateien, in denen Programm-Routinen gelagert werden. Unter Windows kennt man sie als *DLL, unter Unix/Linux werden sie üblicherweise mit der Endung .so abgelegt. Zum Unterschied von statischen Liberies ( .a Dateien) müssen sie im System mindestens einmal vorhanden.
Statische Libaries werden beim make-Lauf in das Programm „kopiert“ und sind damit fixer Bestandteil des Programmes.
Beides hat Vor- und Nachteile ich will da gar keine Partei ergreifen.
Speicher kann ich auf einer Vielzahl von Arten benutzen. Jetzt versucht der Kern auch den Speicher so optimal wie möglich zu organisieren.Nicht benötigte Bereiche werden auf die Festplatte ausgelagert (Swap). Diesen Vorgang läuft unter dem Begriff pageout. Es soll so Programmierer geben die für eine Telefonnummer mit 10 Zeichen, den Speicher für 1 MB anfordern, dann werden 1.048.566 Bytes nicht genutzt 😉 Sollte die Telefonnummer doch länger sein erfolgt ein pagein und der Speicher kann genutzt werden.
Nun ein pageout ist nicht schlimm, viele pageout sind viele Plattenzugriffe. Wenn ich viele Programme mit vielen statischen Libaries laufen habe, dann sind die Programme auch entsprechend gross und benötigen auch entsprechen Platz im Speicher.
Das kann ich im Nornalfall nicht beeinflussen, den solche Änderungen sind aufwendig test- und zeit-intensiv. Hier kann ich mir nur mit einer Hardware behelfen. Hohe Pageout und Swap Werte schreien nach Speicher.
Wenn ich selbst programmiere oder programmieren lasse, dann kann man sich diese Werte gezielt anschauen. Auch dazu gibt es eine Unmenge an Tools wie perf oder sar.
ein File ist ein File ist ein File
und damit verlasse ich die künstlerische Ecke. Und widme mich dem I/O. Da nahezu alles über einen Filedescriptor abgebildet ist, kann man auch mit einfachen Mittel darauf zugreifen. Ob man es tun sollte lasse ich einmal dahingestellt. Aber ich kann mit dem vim Editor auf /dev/mem zugreifen und auch speichern. Ein System-Halt ist ziemlich sicher vordefiniert. Aber ein „cat /proc/meminfo“ gibt mir viele Informationen. (Vielleicht ein nächster Artikel).
Aber zurück zu unserem I/O. Da hätten wir den Unterschied zwischen einem 1 Byte-Auftrag und einem 4 MB Auftrag. Ein Schreibauftrag über 1 Zeichen ist genau so aufwendig ein Auftrag über 4 MB. Ab einer bestimmten Größe bringt aber ein größerer Buffer nichts mehr, weil dann die Hardware nicht mehr mit kann. Bei den meisten Systemen wird das so um die 4MB sein.
Nun top bzw vmstat liefern uns die I/O-Wert als Gesamtes. Wenn ich es etwas genauer wissen will, dann kann ich es mir mit „iotop“ es etwas genauer anschauen.
Ein weiteres „File“ ist das Netzwerk. Auch hier fallen mittlerweile ziemlich viele I/O-Operationen an. Um die Auslastung des Netzwerks zu beobachten gibt es ein kleines Programm iptraf bzw iptraf-ng. Das Programm muss allerdings nachinstalliert werden.
Besonders wenn ihr Glasfaser bis zum Endgerät benutzt, ist ein Blick vielleicht nützlich um einen weiteren Engpass auszuschließen.
Mit diesen Werkzeugen könnt ihr einmal feststellen, ob und wo im System Schwachstellen liegen. Damit ist einmal der erste Schritt getan. Ob man sie einfach beheben kann, steht auf einem anderen Blatt.
Nun gibt es ein paar Kommands um diese Performance etwas zu manipulieren.
Da wäre die nice-Befehle, nice erhöht/vermindert der CPU Anforderungen. Das Programm ist dann so nice und fordert mehr/weniger CPU an. Es läuft dann halt länger/kürzer. „man nice“ gibt mehr Info. ionice macht das Gleiche mit den IO-Anforderungen. Es empfehlt sich auch hier ein Blick in die „man ionice“ zu werfen.
Dann gib es noch ulimt. Ulimit gibt einen Prozess nur bestimmte Resourcen und muss VOR dem Start des Programmes gesetzt werden.
bzw beim Start. Ein Befehl „ulimit -n 10 mein-programm“ erlaubt dem Programm maximal 10 Dateien zu öffnen. So kann man auf CPU-Zeit, Speicher und vieles mehr einengen.
besonders wenn man neue Programme und Versionen hat kann man mit dieser Methode den Bedarf der Programme feststellen. Ja es ist aufwendig und man sollte die Werte auch auf Testsystemen herausfinden.
Solltet ihr an einem Thema Interesse finden und tiefer hinein wachsen wollen, bitte eine Rückmeldung was euch interessiert.
Und zum Schluss
Alle Programme und Tools wurden auf Debian 13.6 Trixi ausgeführt. Einzelne Funktionen können auf anderen Distributionen /Versionen etwas anders lauten/gespeichert sein.
Noch keine Reaktion