1. sudo dd if=/dev/sda of=/dev/null bs=1M iflag=direct
2. atopsar -d 5 # in a second terminal
3. top # in a third terminal

Ergebnisse von atopsar:

19:18:32  disk           busy read/s KB/read  writ/s KB/writ avque avserv _dsk_
...
19:16:50  sda             18%  156.5  1024.0     0.0     0.0   5.0   1.15 ms
19:16:55  sda             18%  156.3  1024.0     0.0     0.0   4.9   1.15 ms
...

Warum wird die Festplattenauslastung ("beschäftigt") als weniger als 100% gemeldet?

Demnach verbraucht topder ddProzess nur 3% einer CPU oder weniger. topbietet auch einen Gesamtbericht über die Hardware- und Software-Interrupt- ( hiund si) Auslastung der System-CPUs, der weniger als 1% beträgt. Ich habe vier CPUs (2 Kerne mit jeweils 2 Threads).

/dev/sdaist eine SATA-Festplatte. Es ist keine SSD, es ist nicht einmal ein Hybrid-SSHD-Laufwerk. Es kann nicht schneller als etwa 150 Megabyte pro Sekunde lesen :-). Dieser Teil der Ergebnisse ist also sinnvoll: 156 read / s * 1024 KB / read = 156 MB / s

Die Kernel-Version ist 5.0.9-200.fc29.x86_64. Ich habe eine ziemlich standardmäßige, unkomplizierte Installation von Fedora Workstation 29. Es ist keine VM. Der IO-Scheduler ist mq-deadline.

Seit der Kernel-Version 5.0 verwendet Fedora die Blockschicht mit mehreren Warteschlangen. Weil die einzelne Warteschlangenblockschicht entfernt wurde :-).

Ich glaube, die Festplattenauslastung wird in einem der Kernel-Iostat-Felder angegebenatopsar -d und daraus atopberechnet . In dem verknüpften Dokument wird "Feld 10 - Anzahl der Millisekunden für E / A" erwähnt. Es gibt auch eine detailliertere Definition, obwohl ich nicht sicher bin, ob die darin erwähnten Funktionen noch in der Blockschicht mit mehreren Warteschlangen vorhanden sind. Soweit ich das beurteilen kann, verwenden Sie beide und verwenden Sie gemeinsamen Code , um dieses Feld 10 zu lesen. (Ich glaube, dieses Feld wird auch von / / verwendet. )atopsar -datopsar -diostat -xmxiostat.py

Zusätzliche Tests

Variante 2: Wechseln zu bs=512k, aber behalten iflag=direct.

dd if=/dev/sda of=/dev/null bs=512k iflag=direct

19:18:32  disk           busy read/s KB/read  writ/s KB/writ avque avserv _dsk_
...
19:18:00  sda             35%  314.0   512.0     0.0     0.0   2.1   1.12 ms
19:18:05  sda             35%  313.6   512.0     0.2     4.0   2.1   1.11 ms

Variante 3: Verwenden bs=1M, aber entfernen iflag=direct. ddverwendet etwa 10% CPU und 35% Festplatte.

dd if=/dev/sda of=/dev/null bs=1M

19:18:32  disk           busy read/s KB/read  writ/s KB/writ avque avserv _dsk_
...
19:21:47  sda             35%  242.3   660.2     0.0     0.0   5.4   1.44 ms
19:21:52  sda             31%  232.3   667.8     0.0     0.0   9.5   1.33 ms

Wie man diese Ergebnisse reproduziert - wesentliche Details

Hüten Sie sich vor dem letzten Test, dh dd ohne iflag=direct

Es ist ein bisschen wie ein Schwein. Ich habe gesehen, dass das System (Mauszeiger) zehn Sekunden oder länger eingefroren ist. Auch wenn ich den Tausch deaktiviert hatte. (Der Test füllt Ihren RAM mit Buff / Cache . Er füllt die inaktive LRU-Liste. Ich denke, der Umsatz entfernt inaktive Cache-Seiten relativ schnell. Gleichzeitig ist die Festplatte mit sequentiellen Lesevorgängen beschäftigt, sodass es bei Bedarf länger dauert Wie schlimm dies wird, hängt wahrscheinlich davon ab, ob der Kernel auch die aktive LRU-Liste umdreht oder zu stark verkleinert. Das heißt, wie gut der aktuelle "Mash einer Reihe verschiedener Algorithmen mit einer Reihe von Modifikationen für Eckfälle und verschiedene Optimierungen abfangen " funktioniert in Ihrem Fall).

Die genauen Ergebnisse des ursprünglichen Tests sind schwer zu reproduzieren.

Manchmal KB/readzeigt als 512statt 1024. In diesem Fall ähneln die anderen Ergebnisse eher den Ergebnissen von bs=512k. Einschließlich, dass es eine Festplattenauslastung von ungefähr 35% anstelle von ungefähr 20% zeigt. Meine Frage steht also in beiden Fällen, der Unterschied ist nur ein bisschen verwirrend.

Ich dachte, der Unterschied könnte auf einige E / A-Vorgänge von anderen Prozessen zurückzuführen sein ... z. B. wenn ich Firefox öffne, um meine Ergebnisse in diese Frage einzubeziehen ... aber ich habe es auch gesehen, ohne dass Firefox ausgeführt wurde.

Ich denke, der Test zeigt tendenziell KB/read= 1024 an, wenn ich ihn nach dem Neustart, der Anmeldung und dem Warten auf die System-E / A auf Null ausführe (z. B. die PackageKit-Prüfung beenden).

Einige zusätzliche Informationen wurden angefordert. Hier sind die zusätzlichen Informationen , die meiner Meinung nach jedoch kein Licht mehr auf die Frage werfen.

Es ist das Ergebnis einer Änderung in Kernel Version 5.0:

block: part_round_stats löschen und auf weniger genaue Zählung umschalten

Wir möchten in CPU-Zähler in_flight konvertieren.

Die Funktion part_round_stats benötigt den in_flight-Zähler im Handumdrehen. Es wäre zu kostspielig, alle Percpu-Variablen im Handumdrehen zu summieren, daher muss er gelöscht werden. part_round_stats wird verwendet, um zwei Zähler zu berechnen - time_in_queue und io_ticks.

time_in_queue kann ohne part_round_stats berechnet werden, indem die Dauer der E / A hinzugefügt wird, wenn die E / A endet (der Wert ist fast so genau wie der zuvor berechnete Wert, außer dass die Zeit für laufende E / A nicht gezählt wird).

io_ticks kann angenähert werden, indem der Wert erhöht wird, wenn E / A gestartet oder beendet wird und sich der Jiffies-Wert geändert hat. Wenn die E / A weniger als einen Augenblick dauern, ist der Wert genauso genau wie der zuvor berechnete Wert. Wenn die E / A mehr als einen Augenblick dauern, können io_ticks hinter dem zuvor berechneten Wert zurückdriften.

( io_tickswird in part_stat_show () verwendet , um den Kernel- E / A- Status für "Feld 10 - Anzahl Millisekunden für E / A" bereitzustellen .)

Dies erklärt meine Ergebnisse sehr gut. In der Fedora-Kernel-Konfiguration beträgt ein " Augenblick " 1 Millisekunde. Ich ddgehe davon aus, dass eine große Lese-E / A, die von eingereicht wird , für mehr als ein oder zwei Sekunden ausstehen kann. Besonders auf meinem System, das eine altmodische mechanische Festplatte verwendet.

Wenn ich zur vorherigen Kernel-Serie 4.20.x zurückkehre, wird die korrekte Festplattenauslastung angezeigt:

$ uname -r
4.20.15-200.fc29.x86_64
$ atopsar -d 5
...
13:27:19  disk           busy read/s KB/read  writ/s KB/writ avque avserv _dsk_
13:28:49  sda             98%  149.4  1024.0    13.0     5.3   2.2   6.04 ms
13:28:54  sda             98%  146.0  1024.0     7.2     5.7   1.5   6.38 ms

Dieser alte Kernel verwendete cfqstandardmäßig die ältere Blockschicht mit einer Warteschlange und standardmäßig den E / A-Scheduler. Das Ergebnis ist auch bei Verwendung des deadlineE / A-Schedulers dasselbe .

Ich bemerkte auch, dass jemand einen Patch vorschlug, um die Annäherung anzupassen. Von Konstantin Khlebnikov:

[PATCH 3/3] Block / Diskstats: Genauere Approximation von io_ticks für langsame Disks

Derzeit wird io_ticks angenähert, indem bei jedem Start und Ende von Anforderungen eine hinzugefügt wird, wenn sich die Anzahl der Änderungen geändert hat. Dies funktioniert perfekt für Anfragen, die kürzer als ein Augenblick sind.

Die Korrektur für langsame Anforderungen ist einfach: Fügen Sie am Ende der Anforderung die Anzahl der seit dem letzten Update übergebenen Jiffies hinzu.

Ich hatte jedoch ein zweites Problem, als ich mir den Code ansah. io_ticksist ein CPU-Status pro CPU. Es scheint auf jeder einzelnen CPU inkrementiert zu sein (und summiert, wenn Sie den Festplattenstatus lesen). Ich gehe also davon aus, dass es zumindest in einigen Fällen auch überzählt werden könnte - dh multipliziert mit der Anzahl der CPUs.

Technisch gesehen gehört der verknüpfte Code zur "Bio-Schicht" . Obwohl die Umstellung auf Statistiken pro CPU sehr schnelle Speichergeräte unterstützen sollte, hängt sie nicht wirklich von den Interna der neuen Anforderungsschicht mit mehreren Warteschlangen ab .