Festplatten IO/s messen?

[Ulli Horlacher]

Festplatten Durchsatz messen ist einfach, aber wie misst man am besten IO/s?
Zusatzbedingung: ohne extra tools zu installieren, es sollte mit jeder
Basisinstallation funktionieren. Perl ist erlaubt :-)

--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/

[Arno Welzel]

Ulli Horlacher, 2023-12-11 09:31:

> Festplatten Durchsatz messen ist einfach, aber wie misst man am besten IO/s?
> Zusatzbedingung: ohne extra tools zu installieren, es sollte mit jeder
> Basisinstallation funktionieren. Perl ist erlaubt :-)

Ohne extra Tools? Gar nicht.

--
Arno Welzel
https://arnowelzel.de

[Christian Garbs]

Mahlzeit!

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:

> Festplatten Durchsatz messen ist einfach, aber wie misst man am besten IO/s?
> Zusatzbedingung: ohne extra tools zu installieren, es sollte mit jeder
> Basisinstallation funktionieren. Perl ist erlaubt :-)

/proc/diskstats parsen? Das mache ich für meine RRD-Statistiken so.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Ho ho ho! I am Santa Claus of Borg.
Nice assimilation all together!

[Ulli Horlacher]

Christian Garbs <mi...@cgarbs.de> wrote:
> Mahlzeit!
>
> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>
>> Festplatten Durchsatz messen ist einfach, aber wie misst man am besten IO/s?
>> Zusatzbedingung: ohne extra tools zu installieren, es sollte mit jeder
>> Basisinstallation funktionieren. Perl ist erlaubt :-)
>
> /proc/diskstats parsen? Das mache ich für meine RRD-Statistiken so.

Dann muesste sich schon was tun.
Ich will aber explizit testen: "Tu was!"

[Markus Schaaf]

Am 11.12.23 um 09:31 schrieb Ulli Horlacher:

> Festplatten Durchsatz messen ist einfach, aber wie misst man am besten IO/s?
> Zusatzbedingung: ohne extra tools zu installieren, es sollte mit jeder
> Basisinstallation funktionieren. Perl ist erlaubt :-)

Entspricht zwar nicht Deiner "Bedingung", aber wenn man
Festplatten benchmarken will, ist das das perfekte Tool:
https://git.kernel.dk/cgit/fio/tree/HOWTO.rst

MfG

[Arno Welzel]

Markus Schaaf, 2023-12-11 12:07:

Aber das wäre ja nicht "ohne extra tools zu installieren".

[Christian Garbs]

Mahlzeit!

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:

> Christian Garbs <mi...@cgarbs.de> wrote:
>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>>
>>> Festplatten Durchsatz messen ist einfach, aber wie misst man am besten IO/s?
>>> Zusatzbedingung: ohne extra tools zu installieren, es sollte mit jeder
>>> Basisinstallation funktionieren. Perl ist erlaubt :-)
>>
>> /proc/diskstats parsen? Das mache ich für meine RRD-Statistiken so.
>
> Dann muesste sich schon was tun.
> Ich will aber explizit testen: "Tu was!"

Ah, Du willst einen Benchmark machen und nicht gucken, wie beschäftigt
das System gerade ist. Schreib das doch :)

Mit Perl sollte es möglich sein, eine große Datei zu erzeugen und dann
wild darin zu schreiben – dann hast Du I/O.

Wobei ich mir jetzt nicht sicher bin, wie man dem open() Flags wie
O_SYNC oder O_DSYNC übergibt, damit man nicht nur den Buffer-Cache
testet.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

All My Circuits - The Movie

[Ulli Horlacher]

Christian Garbs <mi...@cgarbs.de> wrote:
> Mahlzeit!
>
> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>> Christian Garbs <mi...@cgarbs.de> wrote:
>>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>>>
>>>> Festplatten Durchsatz messen ist einfach, aber wie misst man am besten IO/s?
>>>> Zusatzbedingung: ohne extra tools zu installieren, es sollte mit jeder
>>>> Basisinstallation funktionieren. Perl ist erlaubt :-)
>>>
>>> /proc/diskstats parsen? Das mache ich für meine RRD-Statistiken so.
>>
>> Dann muesste sich schon was tun.
>> Ich will aber explizit testen: "Tu was!"
>
> Ah, Du willst einen Benchmark machen und nicht gucken, wie beschäftigt
> das System gerade ist. Schreib das doch :)

Sag ich doch :-)

Ich nehm jetzt "find . -xdev |wc -l" und mess dazu die Zeit.

Integriert hab ichs in fsbm:

root@moep:/# fsbm 500
write test on / :
524288000 bytes (524 MB, 500 MiB) copied, 1.15847 s, 453 MB/s
read test:
524288000 bytes (524 MB, 500 MiB) copied, 0.928931 s, 564 MB/s
IO: 490810 files in 0.7 seconds = 696307 IO/s


https://fex.belwue.de/linuxtools/

[Christian Garbs]

Mahlzeit!

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:

>>> Christian Garbs <mi...@cgarbs.de> wrote:
>>>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>>>>
>>>>> Festplatten Durchsatz messen ist einfach, aber wie misst man am
>>>>> besten IO/s? Zusatzbedingung: ohne extra tools zu installieren,
>>>>> es sollte mit jeder Basisinstallation funktionieren. Perl ist
>>>>> erlaubt :-)
>>>>
>>>> /proc/diskstats parsen? Das mache ich für meine RRD-Statistiken so.

> Ich nehm jetzt "find . -xdev |wc -l" und mess dazu die Zeit.
>
> Integriert hab ichs in fsbm:
>
> root@moep:/# fsbm 500
> write test on / :
> 524288000 bytes (524 MB, 500 MiB) copied, 1.15847 s, 453 MB/s
> read test:
> 524288000 bytes (524 MB, 500 MiB) copied, 0.928931 s, 564 MB/s
> IO: 490810 files in 0.7 seconds = 696307 IO/s

Wie kommst Du von "gelesenen Files" auf "IO/s"?

- Metadaten werden gerne gecached.

- Wenn find(1) _einen_ Directory-Inode liest, dürften da die
Metadaten von _mehreren_ Dateien drinstehen.

- Du misst etwas auf Dateisystem-Ebene, das neben dem verwendeten
Dateisystem ggf. noch von irgendwelchen Raid-Leveln und
Device-Mappern beeinflusst wird, willst aber eigentlich die IO/s
der Hardware messen.

Ich glaube nicht, dass das, was Du da misst, groß mit Hardware-IO/s
korrelliert.

Lies /proc/diskstats, mach dann das find(1), lies nochmal
/proc/diskstats und bilde das Delta über die IO-Zähler.

Was für Zahlen kommen da dann raus?

Gruß
Christian

PS: Oder gib im Skript halt aus "find(1) hat X Dateien in Y Sekunden
gefunden" und lass den Begriff "IO/s" weg ;-)
--
....Christian.Garbs....................................https://www.cgarbs.de
See, these two penguins walked into a bar, which was really stupid,
'cause the second one should have seen it.

[Ulli Horlacher]

Christian Garbs <mi...@cgarbs.de> wrote:

>> Ich nehm jetzt "find . -xdev |wc -l" und mess dazu die Zeit.
>>
>> Integriert hab ichs in fsbm:
>>
>> root@moep:/# fsbm 500
>> write test on / :
>> 524288000 bytes (524 MB, 500 MiB) copied, 1.15847 s, 453 MB/s
>> read test:
>> 524288000 bytes (524 MB, 500 MiB) copied, 0.928931 s, 564 MB/s
>> IO: 490810 files in 0.7 seconds = 696307 IO/s
>
> Wie kommst Du von "gelesenen Files" auf "IO/s"?
>
> - Metadaten werden gerne gecached.

Ich schmeiss den pagecache vorher weg.

root@moep:/# fsbm -v 500
write test on / :
# dd status=progress bs=4M count=125 conv=fdatasync oflag=direct if=/dev/zero of=fsbm_dd.tmp
524288000 bytes (524 MB, 500 MiB) copied, 1.13576 s, 462 MB/s
read test:
# echo 3 > /proc/sys/vm/drop_caches
# dd status=progress bs=4M if=fsbm_dd.tmp of=/dev/zero
524288000 bytes (524 MB, 500 MiB) copied, 0.937004 s, 560 MB/s
# echo 3 > /proc/sys/vm/drop_caches
# find . -xdev | wc -l
IO: 490799 files in 0.8 seconds = 652789 read/s

> - Wenn find(1) _einen_ Directory-Inode liest, dürften da die
> Metadaten von _mehreren_ Dateien drinstehen.

Jeder filename sollte ein eigener Inode sein.

> - Du misst etwas auf Dateisystem-Ebene, das neben dem verwendeten
> Dateisystem ggf. noch von irgendwelchen Raid-Leveln und
> Device-Mappern beeinflusst wird, willst aber eigentlich die IO/s
> der Hardware messen.

Ist bekannt. Mich interessiert aber tatsaechlich nur das logical volume.

> Ich glaube nicht, dass das, was Du da misst, groß mit Hardware-IO/s
> korrelliert.

Zum Vergleich ("welche disk ist schneller?") ist es ausreichend.

> Lies /proc/diskstats, mach dann das find(1), lies nochmal
> /proc/diskstats und bilde das Delta über die IO-Zähler.

Welches Datum davon?

https://www.kernel.org/doc/Documentation/ABI/testing/procfs-diskstats

> PS: Oder gib im Skript halt aus "find(1) hat X Dateien in Y Sekunden
> gefunden" und lass den Begriff "IO/s" weg ;-)

Das laesst sich dann nicht mehr vergleichen.
Ich geb jetzt read/s statt IO/s aus.

[Ulli Horlacher]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:

>> - Wenn find(1) _einen_ Directory-Inode liest, dürften da die
>> Metadaten von _mehreren_ Dateien drinstehen.
>
> Jeder filename sollte ein eigener Inode sein.

Korrektur: der filename ist nicht ein eigner indode, ich hatte das
verwechselt.

Also macht fsbm jetzt:

root@moep:/# fsbm -v 500
write test on / :
# dd status=progress bs=4M count=125 conv=fdatasync oflag=direct if=/dev/zero of=fsbm_dd.tmp

524288000 bytes (524 MB, 500 MiB) copied, 1.13945 s, 460 MB/s

read test:
# echo 3 > /proc/sys/vm/drop_caches
# dd status=progress bs=4M if=fsbm_dd.tmp of=/dev/zero

524288000 bytes (524 MB, 500 MiB) copied, 0.929583 s, 564 MB/s
# echo 3 > /proc/sys/vm/drop_caches
# find . -xdev -printf "%U\n" | wc -l
IO: 490804 files in 2.7 seconds = 179531 read/s


%U ist die UID des files und dazu muss find den ersten inode des files
lesen.
Bleibt noch der CPU Overhead des find Programms. Den muesste man von der
Zeit abziehen. Hmmmm... "/usr/bin/time -f %S ..."?
Also nur die system-time?

[Christian Garbs]

Mahlzeit!

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> Christian Garbs <mi...@cgarbs.de> wrote:

>> Wie kommst Du von "gelesenen Files" auf "IO/s"?

[…]

>> - Wenn find(1) _einen_ Directory-Inode liest, dürften da die
>> Metadaten von _mehreren_ Dateien drinstehen.
>
> Jeder filename sollte ein eigener Inode sein.

Ich meine, dass besonders kurze Dateien komplett im Directory-Inode
enthalten sein können. Bei kurzen Dateinamen passen ggf. die
Dateiattribute mit ins Directory rein, auch wenn die Datei größer ist.

Wir sollten nach dcoul.misc umziehen, dann erklärt uns das vielleicht
jemand ;-)

>> Lies /proc/diskstats, mach dann das find(1), lies nochmal
>> /proc/diskstats und bilde das Delta über die IO-Zähler.
>
> Welches Datum davon?
>
> https://www.kernel.org/doc/Documentation/ABI/testing/procfs-diskstats

Ich würde "4 reads completed successfully" nehmen. Aber eigentlich
musst Du ja wissen, was Du genau messen willst :-P

Ganz unten ist noch ein Verweis auf
https://www.kernel.org/doc/Documentation/admin-guide/iostats.rst, das
ist nochmal ausführlicher.

Allerdings ist in dem Dokument irgendwie die Feldreihenfolge anders O_o
Field 4 ist dort "# of milliseconds spent reading (unsigned int)".
Im ersten Dokument steht das in Feld 11.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

"A radioactive cat has eighteen half-lives."

[Ulli Horlacher]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:

> # find . -xdev -printf "%U\n" | wc -l
> IO: 490804 files in 2.7 seconds = 179531 read/s
>
> %U ist die UID des files und dazu muss find den ersten inode des files
> lesen.
> Bleibt noch der CPU Overhead des find Programms. Den muesste man von der
> Zeit abziehen. Hmmmm... "/usr/bin/time -f %S ..."?
> Also nur die system-time?

Genau andersrum :-}
system und user time ist nur die CPU Zeit.
Warten auf disk IO geht nur in die real time ein. Also muss ich system und
user time davon abziehen. Dann weiss ich wieviel Zeit die disk vertroedelt.

[Marcus Jodorf]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> schrieb:

> Dann weiss ich wieviel Zeit die disk vertroedelt.

Normale Menschen nehmen ja einfach vorhandene Tools, in die andere
Menschen netterweise schon Gehirnschmalz gesteckt haben.

root@foobar:~# iostat -p nvme0n1 -x -m -h
Linux 6.5.0-5-amd64 (foobar) 12/14/2023 _x86_64_ (64 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
1.6% 0.0% 0.4% 0.2% 0.0% 97.7%

r/s rMB/s rrqm/s %rrqm r_await rareq-sz Device
2.64 218.6k 0.00 0.0% 0.18 82.8k nvme0n1
0.00 0.1k 0.00 0.0% 0.17 23.1k nvme0n1p1
0.00 0.4k 0.00 0.0% 0.19 71.0k nvme0n1p2
2.63 218.2k 0.00 0.0% 0.18 82.9k nvme0n1p3

w/s wMB/s wrqm/s %wrqm w_await wareq-sz Device
12.66 206.2k 0.00 0.0% 0.31 16.3k nvme0n1
0.00 0.0k 0.00 0.0% 0.00 0.5k nvme0n1p1
0.02 0.2k 0.00 0.0% 0.13 10.0k nvme0n1p2
12.65 206.0k 0.00 0.0% 0.31 16.3k nvme0n1p3

d/s dMB/s drqm/s %drqm d_await dareq-sz Device
1.22 829.4k 0.00 0.0% 0.56 680.9k nvme0n1
0.00 0.0k 0.00 0.0% 0.00 0.0k nvme0n1p1
0.00 0.1k 0.00 0.0% 2.74 75.1k nvme0n1p2
1.22 829.3k 0.00 0.0% 0.56 681.3k nvme0n1p3

f/s f_await aqu-sz %util Device
0.59 1.40 0.01 1.0% nvme0n1
0.00 0.00 0.00 0.0% nvme0n1p1
0.00 0.00 0.00 0.0% nvme0n1p2
0.00 0.00 0.01 1.0% nvme0n1p3

Das zeigt Dir dann auch Sachen wie average queue length per request
(aqu-sz) und die await-Werte sind die Durchschnittszeiten in ms, die requests
jeweils bis zur Vollendung benötigt haben. Was letztlich interessanter
ist, weil das ist quasi, was am Ende an Tempo rauskommt.

apt-get install sysstat bzw. yum install sysstat.

Oder schau in den Code, wo und wie die Werte ermittelt werden und laß
Dich inspirieren ;-)



Gruß,

Marcus
⚂⚃

[Thomas Dorner]

Christian Garbs <mi...@cgarbs.de> writes:
>> https://www.kernel.org/doc/Documentation/ABI/testing/procfs-diskstats
>
> Ich würde "4 reads completed successfully" nehmen. Aber eigentlich
> musst Du ja wissen, was Du genau messen willst :-P
>
> Ganz unten ist noch ein Verweis auf
> https://www.kernel.org/doc/Documentation/admin-guide/iostats.rst, das
> ist nochmal ausführlicher.
>
> Allerdings ist in dem Dokument irgendwie die Feldreihenfolge anders O_o
> Field 4 ist dort "# of milliseconds spent reading (unsigned int)".
> Im ersten Dokument steht das in Feld 11.

Nein, die Feldreihenfolge ist nicht anders. Erstens steht in
iostats.rst "the statistics fields are those after the device name" -
damit sind die beiden Listen um 3 verschoben (major/minor number und
device name). Zweitens ist #11 in procfs-diskstats "time spent writing
(ms)". Reading ist die korrekt verschobene #7. Und #4 (aka #1 in
iostats.rst) ist nur die Anzahl. ("This is the total number of reads
completed successfully.")

Viele Grüße, Thomas
--
Adresse gilt nur kurzzeitig!

[Ulli Horlacher]

Marcus Jodorf <m...@bogomips.de> wrote:

> Normale Menschen nehmen ja einfach vorhandene Tools, in die andere
> Menschen netterweise schon Gehirnschmalz gesteckt haben.

Ich bin ja faul und programmiere nur in Notwehr.
Wenn ich also nichts brauchbares finde.

> root@foobar:~# iostat -p nvme0n1 -x -m -h

Das ist fuer mich nicht brauchbar, denn es zeigt nur an, was bisher die
Platte gemacht hat. Wenn es da keine Zugriffe gab, zeigt es logischerweise
auch nichts an.

Ich brauch also ein tool, das erstmal IO erzeugt.

> Oder schau in den Code, wo und wie die Werte ermittelt werden und laß
> Dich inspirieren ;-)

Ich kann kein C mehr, das hab ich zuletzt vor 30 Jahren verwendet.

[Diedrich Ehlerding]

Ulli Horlacher meinte:

> Ich brauch also ein tool, das erstmal IO erzeugt.

Google nach "fio"
>
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.

[Christian Garbs]

Mahlzeit!

Thomas Dorner <dcoulh231...@spamgourmet.com> wrote:
> Christian Garbs <mi...@cgarbs.de> writes:

[ https://www.kernel.org/doc/Documentation/ABI/testing/procfs-diskstats

vs. https://www.kernel.org/doc/Documentation/admin-guide/iostats.rst ]

>> Allerdings ist in dem Dokument irgendwie die Feldreihenfolge anders O_o
>> Field 4 ist dort "# of milliseconds spent reading (unsigned int)".
>> Im ersten Dokument steht das in Feld 11.

> Nein, die Feldreihenfolge ist nicht anders. Erstens steht in
> iostats.rst "the statistics fields are those after the device name" -
> damit sind die beiden Listen um 3 verschoben (major/minor number und
> device name). Zweitens ist #11 in procfs-diskstats "time spent writing
> (ms)". Reading ist die korrekt verschobene #7. Und #4 (aka #1 in
> iostats.rst) ist nur die Anzahl. ("This is the total number of reads
> completed successfully.")

Danke! Zu viel Überflugmodus beim Lesen ;-)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

When you have to kill a man it costs nothing to be polite.
-- Winston Churchill, on formal declarations of war

[Ulli Horlacher]

Diedrich Ehlerding <diedrich....@t-online.de> wrote:
> Ulli Horlacher meinte:
>
>> Ich brauch also ein tool, das erstmal IO erzeugt.
>
> Google nach "fio"

Viel zu kompliziert.
Die man-page hat ueber 4000 Zeilen!
Da braucht nman ja Tage um das zu verstehen!

[Georg Schwarz]

Kennt jemand ein Tool, das (u.a.) den akutellen Schreib- und
Lesedurchsatz auf eine Platte anzeigt, ähnlich wie viele Tools es für
den aktuellen Speicherverbrauch, CPU- oder Netzwerknutzung tun?

[Markus Schaaf]

Am 15.12.23 um 17:30 schrieb Georg Schwarz:

> Kennt jemand ein Tool, das (u.a.) den akutellen Schreib- und
> Lesedurchsatz auf eine Platte anzeigt, ähnlich wie viele Tools es für
> den aktuellen Speicherverbrauch, CPU- oder Netzwerknutzung tun?

iotop

[Christian Garbs]

Mahlzeit!

Danke für die Frage - ich hatte bisher nur iotop(1) im Kopf, das zeigt
aber pro Prozess, nicht pro Device an. Ich bin jetzt auf iostat(1)
gestoßen, das macht, was Du willst:

% iostat -d 2

zeigt alle 2 Sekunden die Auslastung der Block-Devices an

% iostat -p 5

zeigt alle 5 Sekunden die Auslastung aller Block-Devices und
Partitionen an.

Die initiale Anzeige bezieht sich immer auf "seit Boot", erst nach der
ersten Pause kommen aktuelle Daten. Mit "-y" kannst Du die erste
Ausgabe "seit Boot" unterdrücken.

Bei Debian ist das Tool im Paket "sysstat" enthalten.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Die drei Feinde des Programmierers?
Sonnenlicht, Frischluft und das unerträgliche Gebrüll der Vögel.

[Georg Schwarz]

Christian Garbs <mi...@cgarbs.de> wrote:

> Bei Debian ist das Tool im Paket "sysstat" enthalten.

bei Manjaro auch

[Georg Schwarz]

Christian Garbs <mi...@cgarbs.de> wrote:


> Danke für die Frage - ich hatte bisher nur iotop(1) im Kopf, das zeigt
> aber pro Prozess, nicht pro Device an. Ich bin jetzt auf iostat(1)
> gestoßen, das macht, was Du willst:

Nett. Danke.
Gibt's auch ein Tool, das den Zeitverlauf als Kurve darstellt, so
ähnlich wie ksysguard oder Systemmonitor bzw. könnte man das ggfs. in
diese integrieren?

[Nico Hoffmann]

Georg Schwarz schreibt:

> Kennt jemand ein Tool, das (u.a.) den akutellen Schreib- und
> Lesedurchsatz auf eine Platte anzeigt, ähnlich wie viele Tools es für
> den aktuellen Speicherverbrauch, CPU- oder Netzwerknutzung tun?

hdparm und dd, wie in
https://wiki.ubuntuusers.de/Festplatten-Geschwindigkeitstest/ ?

N.
--
Der Regenbogen ist eine Entschuldigung für das schlechte Wetter.

[Christian Garbs]

Mahlzeit!

Georg Schwarz <georg....@freenet.de> wrote:

> Nett. Danke.
> Gibt's auch ein Tool, das den Zeitverlauf als Kurve darstellt, so
> ähnlich wie ksysguard oder Systemmonitor bzw. könnte man das ggfs. in
> diese integrieren?

Bestimmt, aber ich kenne keines - mein Monitoring läuft anders ;)

iostat(1) kann die Daten so ausgeben, dass sie sich leicht
weiterverarbeiten lassen (-t, -o JSON, --compact), da kann man sich
bedarfsgerecht was skripten. Leider gibt's wohl keine Option, die
initiale Überschrift (hostname + CPU-Anzahl) wegzubekommen.

Wenn Du selbst was baust, kannst Du aber vermutlich gleich die
Rohdaten aus /proc/diskstats lesen, statt mühsam den iostats(1)-Output
zu parsen.

Gruß
Christian

PS: Hier™ misst das Skript io.pl aus https://github.com/mmitch/rrd
alle 5 Minuten die Werte aus /proc/diskstats und malt daraus dann
sowas: https://www.cgarbs.de/tmp/io-day.png
--
....Christian.Garbs....................................https://www.cgarbs.de
Kinder auf dem Rücksitz erzeugen Unfälle,
Unfälle auf dem Rücksitz erzeugen Kinder.

[Ulli Horlacher]

Nico Hoffmann <oxen...@gmx.de> wrote:
> Georg Schwarz schreibt:
>
>> Kennt jemand ein Tool, das (u.a.) den akutellen Schreib- und
>> Lesedurchsatz auf eine Platte anzeigt, ähnlich wie viele Tools es für
>> den aktuellen Speicherverbrauch, CPU- oder Netzwerknutzung tun?
>
> hdparm und dd, wie in
> https://wiki.ubuntuusers.de/Festplatten-Geschwindigkeitstest/ ?

Du hast "aktuell" ueberlesen.

hdparm und dd ERZEUGEN Last.