Ich betrachte dieses Problem aus der Sicht eines Entwicklers. Ich schreibe den Code, der auf einer virtuellen RHEL-Maschine platziert wird, die als eine von vielen in einem Unternehmenssystem ausgeführt wird. Das verwendete Dateisystem ist ein Remote-, Netzwerkspeichergerät.
Wir hatten während der Batchverarbeitung eine hohe Variabilität bei einfachen Befehlen. Also haben wir einen Test eingerichtet, um mehr Informationen zu erhalten, aber jetzt weiß ich nicht, was wir herausgefunden haben.
Wir haben den folgenden Befehl alle 30 Minuten ausgeführt und die Ausgabe protokolliert. Es handelt sich um eine Kopie einer 6 GB großen Datei. Was ich sehe, ist ein Sprung der verstrichenen Zeit von 11 Sekunden auf 190 Sekunden, wenn das System mit der Ausführung vieler Jobs beschäftigt ist und dieser Testbefehl nur wenig CPU-Zeit benötigt.
Was ich sehen kann, ist, dass die Spalte „I“ (Dateisystemeingaben) gefüllt wird, wenn die CPU-Auslastung niedrig ist, aber nicht, wenn sie hoch ist. Die Spalte „w“ (unfreiwillige Swaps) ist auch viel höher.
Meine Frage ist, was passiert mit diesem Job/Befehl, das ihn dazu zwingt, SO VIEL LÄNGER zu laufen, wenn die CPU-Zeit abnimmt? Werden beim Swap-In/Out alle diese Daten auf einem anderen Gerät gespeichert, das viel langsamer ist? Was passiert im Allgemeinen während eines Swap-In/Out?
Ausgeführter Befehl:
/usr/bin/time -a -o filename.txt cp file.txt fileCopy.txt
| Datum | Zeit | t | S | U | P | C | m | ICH | Ö |
|---|---|---|---|---|---|---|---|---|---|
| 14.03.2022 | 5:19:02 | 64,9 | 16.23 | 1.03 | 26 % | 3005 | 29210 | 12000016 | 12000000 |
| 14.03.2022 | 5:49:02 | 12.7 | 11,63 | 0,79 | 97 % | 2069 | 76 | 0 | 12000000 |
| 14.03.2022 | 6:19:02 | 100,39 | 14,74 | 0,78 | 15% | 1034 | 29925 | 12000136 | 12000000 |
| 14.03.2022 | 6:49:24 | 191,32 | 18,86 | 0,94 | 10 % | 3374 | 36164 | 12001024 | 12000000 |
| 14.03.2022 | 7:19:02 | 71,61 | 15.61 | 0,88 | 23 % | 1610 | 30316 | 12000296 | 12000000 |
| 14.03.2022 | 7:49:02 | 70,73 | 17,5 | 0,91 | 26 % | 1408 | 29540 | 12000072 | 12000000 |
| 14.03.2022 | 8:19:02 | 10,95 | 9,89 | 0,7 | 96 % | 1709 | 75 | 0 | 12000000 |
| 14.03.2022 | 8:49:02 | 11.01 | 10.22 | 0,73 | 99 % | 239 | 85 | 0 | 12000000 |
Die Spaltenbeschreibungen aus der Manpage für /usr/bin/time
e Elapsed real time (in seconds).
S Total number of CPU-seconds that the process spent in kernel mode.
U Total number of CPU-seconds that the process spent in user mode.
P Percentage of the CPU that this job got, computed as (%U + %S) / %E.
c Number of times the process was context-switched involuntarily (because the time slice expired).
w Number of waits: times that the program was context-switched voluntarily, for instance while waiting for an I/O operation to complete.
I Number of filesystem inputs by the process.
O Number of filesystem outputs by the process.
Antwort1
P bedeutet in diesem Zusammenhang das Verhältnis der CPU-Zeit, die dieser Job benötigte, zur gesamten verstrichenen Zeit. Nahezu 100 % bedeutet, dass er fast die ganze Zeit auf der CPU lag und die CPU daher für diese Läufe eingeschränkt war. Im Gegensatz zu den anderen Läufen, bei denen etwas anderes der begrenzende Faktor war. Mehr Systemzeit (auch Kernelzeit genannt) als Systemzeit, wie es für E/A-intensive Aufgaben typisch ist.
Da die Arbeitslast darin bestand, eine 6 GB große Datei zu kopieren, können wir davon ausgehen, dass die 11 Sekunden dauernden Läufe durchschnittlich mehr als 0,5 GB Schreibvorgänge pro Sekunde ergaben. Spalte O bestätigt jedes Mal die gleiche Anzahl an Schreibvorgängen, was mit einem einfachen Kopiervorgang für eine Datei übereinstimmt.
Die Eingabespalte weist jedoch große Schwankungen auf. Bei langsamen Läufen werden ungefähr gleich viele gelesen wie geschrieben. Bei schnellen Läufen wird jedoch nicht gelesen! Ich gehe davon aus, dass die Datei noch vom letzten Lesevorgang im RAM zwischengespeichert ist. DRAM ist sogar viel schneller als Solid-State-Speicher. Das ist ein großer Geschwindigkeitsschub, bis das Betriebssystem unter Speicherdruck die zwischengespeicherten Daten löscht und erneut vom langsamen Speicher lesen muss.
Dies ist also eine 200-Sekunden-Aufgabe, die gelegentlich 12 Sekunden dauern kann. Wahrscheinlich aufgrund des Linux-Seitencaches.
Um die Grundursache eines Leistungsproblems zu finden, ist häufig ein tieferes Verständnis des Gesamtsystems erforderlich, das über einen bestimmten Satz von Kennzahlen hinausgeht.
Das verwendete Dateisystem ist ein entferntes, an das Netzwerk angeschlossenes Speichergerät.
Beachten Sie, dass Ihre Kopie über einen Netzwerkspeicher erfolgt, es könnte also auch alles auf dem Remote-System oder dem Netzwerk dazwischen sein. Remote-Speicherleistung. Netzwerkgeschwindigkeit (wahrscheinlich IP) und -auslastung. Oder es könnte lokal auf dieser VM sein, wo der Gast mit allem anderen, was auf Ihrer Infrastruktur läuft, um Ressourcen konkurriert.
Es ist immer möglich, tiefer in die Funktionsweise einzusteigen. Ist Netzwerkspeicher (NFS?) überhaupt wichtig oder sehen Sie dies auch für lokale Festplatten? 0,7 Sekunden CPU-Zeit des Benutzers sind tatsächlich eine ganze Menge Arbeit. Wie viel kostet die Verwaltung vieler Systemaufrufe? Was bedeutet „CPU ausgelastet“ eigentlich, wenn die meiste Zeit auf langsamen Speicher und sehr langsamen Speicher gewartet wird? Diese Fragen sind nicht leicht zu beantworten, aber vielleicht besteht kein Grund, zu tief zu graben, wenn die Leistung erst einmal angemessen ist.