SSD/Festplatten-Benchmarking (war: Re: [Semi OT] Suche neues Board für alte Hardware)
Am Freitag, 29. Juli 2011 schrieb Michelle Konzack:
> Hello Martin Steigerwald,
Sodele,
Butter aufs Brot:
> Am 2011-07-29 13:08:58, hacktest Du folgendes herunter:
> > Bitte was?
> >
> > "Unter Linux bringt eine SSD nicht so wirklich viel." als Pauschal-
> > Aussage?
> >
> > Der Umstieg von Festplatte auf SSD ist für mich gefühlt ein Schritt
> > wie der Umstieg von Diskette auf Festplatte.
>
> Ehm, also ich habe eine meiner Sun Fire X4100M2 mit 4 SSD
> Platten ausgerüstet und die sind in keinster weise schneller als die
> original 300 GByte SAS Platten...
>
> Und beim Stromverbrauch ist es auch egal, ob die Kiste jetzt 340
> Watt verbraucht oder vorher 360 Watt läßt sich sowieso nicht exakt
> messen.
>
> SSD ist einfach nur enttäuschend und Geldbeutel leerend.
Nun, 300 GByte SAS-Platten sind zunächst mal was Anderes, als das was in
typischen Desktop- oder Notebook-Systemen verbaut ist. Aber im Server-
Umfeld natürlich durchaus typisch.
Die Aussage "sind in keinster weise schneller" kaufe ich Dir ohne
vergleichende Messungen aber nicht ab. Und mit Messungen meine ich *nicht
nur* sequentielles I/O. Da mögen sich die SAS-Platten und eine SATA 300-
SSD nicht viel geben. Bei einer SATA 600-SSD mit 400-500 MB/s sequentiell
dürfte das wieder anders aussehen.
Die IOPS mit z.B. 2-16 KB Blockgröße sind da durchaus interessanter.
Ok, ich mache mal einen Anfang. Ich bin noch (bei weitem) nicht sicher,
die besten Parameter getroffen zu haben, aber zum Einstieg mal:
martin@merkaba:~[…]> cat iops.job
[global]
size=2G
bsrange=2-16k
filename=iops1
numjobs=1
iodepth=1
# Zufällige Daten für SSDs, die komprimieren
refill_buffers=1
[zufälligschreiben]
rw=randwrite
stonewall
[sequentiellschreiben]
rw=write
stonewall
[zufälliglesen]
rw=randread
stonewall
[sequentielllesen]
rw=read
Für IOPS-Messungen ist empfohlen, über das gesamte Gerät zu messen. Diesen
Luxus lasse ich mit der SSD aber mal. 2 GB sind schonmal ganz nett als
Start.
fio schmeißt vor einem IO-Job die Daten weg. Standard-Engine ist Sync I/O,
das heißt fio weist den Linux Kernel an, sofort zu schreiben. Zufällig
füllt fio mit refill_buffer den Buffer fürs Schreiben vor jedem Schreiben neu
mit zufälligen Daten.
Die Intel SSD 320 komprimiert meines ungefähren Wissens nicht, aber SSDs
mit neurerem Sandforce-Chip tun dies.
Das ganze sieht dann so aus:
martin@merkaba:~[…]> ./fio iops.job
zufälligschreiben: (g=0): rw=randwrite, bs=2-16K/2-16K, ioengine=sync,
iodepth=1
sequentiellschreiben: (g=1): rw=write, bs=2-16K/2-16K, ioengine=sync,
iodepth=1
zufälliglesen: (g=2): rw=randread, bs=2-16K/2-16K, ioengine=sync,
iodepth=1
sequentielllesen: (g=2): rw=read, bs=2-16K/2-16K, ioengine=sync, iodepth=1
fio 1.57
Starting 4 processes
Jobs: 1 (f=1): [__r_] [100.0% done] [561.9M/0K /s] [339K/0 iops] [eta
00m:00s]
zufälligschreiben: (groupid=0, jobs=1): err= 0: pid=23221
write: io=2048.0MB, bw=16971KB/s, iops=5190 , runt=123573msec
clat (usec): min=0 , max=275675 , avg=183.76, stdev=989.34
lat (usec): min=0 , max=275675 , avg=184.02, stdev=989.36
bw (KB/s) : min= 353, max=94417, per=99.87%, avg=16947.64,
stdev=11562.05
cpu : usr=5.39%, sys=14.47%, ctx=344861, majf=0, minf=30
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%,
>=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
>=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
>=64=0.0%
issued r/w/d: total=0/641383/0, short=0/0/0
lat (usec): 2=4.48%, 4=23.03%, 10=27.46%, 20=5.22%, 50=2.17%
lat (usec): 100=0.08%, 250=10.16%, 500=21.35%, 750=4.79%, 1000=0.06%
lat (msec): 2=0.13%, 4=0.64%, 10=0.40%, 20=0.01%, 50=0.01%
lat (msec): 100=0.01%, 250=0.01%, 500=0.01%
sequentiellschreiben: (groupid=1, jobs=1): err= 0: pid=23227
write: io=2048.0MB, bw=49431KB/s, iops=6172 , runt= 42426msec
clat (usec): min=0 , max=83105 , avg=134.18, stdev=1286.14
lat (usec): min=0 , max=83105 , avg=134.53, stdev=1286.14
bw (KB/s) : min= 0, max=73767, per=109.57%, avg=54162.16,
stdev=22989.92
cpu : usr=10.29%, sys=22.17%, ctx=232818, majf=0, minf=33
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%,
>=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
>=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
>=64=0.0%
issued r/w/d: total=0/261869/0, short=0/0/0
lat (usec): 2=0.10%, 4=1.16%, 10=9.97%, 20=1.14%, 50=0.09%
lat (usec): 100=27.31%, 250=59.37%, 500=0.61%, 750=0.04%, 1000=0.02%
lat (msec): 2=0.04%, 4=0.06%, 10=0.01%, 20=0.06%, 50=0.01%
lat (msec): 100=0.03%
zufälliglesen: (groupid=2, jobs=1): err= 0: pid=23564
read : io=2048.0MB, bw=198312KB/s, iops=60635 , runt= 10575msec
clat (usec): min=0 , max=103758 , avg=14.46, stdev=1058.66
lat (usec): min=0 , max=103758 , avg=14.50, stdev=1058.66
bw (KB/s) : min= 98, max=1996998, per=54.76%, avg=217197.79,
stdev=563543.94
cpu : usr=11.20%, sys=8.25%, ctx=513, majf=0, minf=28
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%,
>=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
>=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
>=64=0.0%
issued r/w/d: total=641220/0/0, short=0/0/0
lat (usec): 2=77.54%, 4=21.11%, 10=1.19%, 20=0.09%, 50=0.01%
lat (usec): 100=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%
lat (msec): 2=0.01%, 4=0.03%, 10=0.01%, 20=0.01%, 50=0.01%
lat (msec): 100=0.01%, 250=0.01%
sequentielllesen: (groupid=2, jobs=1): err= 0: pid=23565
read : io=2048.0MB, bw=235953KB/s, iops=29458 , runt= 8888msec
clat (usec): min=0 , max=71904 , avg=30.61, stdev=278.25
lat (usec): min=0 , max=71904 , avg=30.71, stdev=278.25
bw (KB/s) : min= 2, max=266240, per=59.04%, avg=234162.53,
stdev=63283.64
cpu : usr=3.42%, sys=16.70%, ctx=8326, majf=0, minf=28
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%,
>=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
>=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%,
>=64=0.0%
issued r/w/d: total=261826/0/0, short=0/0/0
lat (usec): 2=28.95%, 4=46.75%, 10=19.20%, 20=1.80%, 50=0.17%
lat (usec): 100=0.11%, 250=0.05%, 500=0.05%, 750=0.24%, 1000=2.44%
lat (msec): 2=0.15%, 4=0.08%, 10=0.01%, 20=0.01%, 100=0.01%
Run status group 0 (all jobs):
WRITE: io=2048.0MB, aggrb=16970KB/s, minb=17378KB/s, maxb=17378KB/s,
mint=123573msec, maxt=123573msec
Run status group 1 (all jobs):
WRITE: io=2048.0MB, aggrb=49430KB/s, minb=50617KB/s, maxb=50617KB/s,
mint=42426msec, maxt=42426msec
Run status group 2 (all jobs):
READ: io=4096.0MB, aggrb=396624KB/s, minb=203071KB/s, maxb=241616KB/s,
mint=8888msec, maxt=10575msec
Disk stats (read/write):
dm-2: ios=577687/390944, merge=0/0, ticks=141180/6046100,
in_queue=6187964, util=76.63%, aggrios=577469/390258, aggrmerge=216/761,
aggrticks=140576/6004336, aggrin_queue=6144016, aggrutil=76.38%
sda: ios=577469/390258, merge=216/761, ticks=140576/6004336,
in_queue=6144016, util=76.38%
Über 5000 IOPS beim zufälligen Schreiben, über 6000 IOPS beim
sequentiellen Schreiben, über 60000 IOPS beim zufälligen Lesen und
merkwürdigerweise nur über 29000 IOPS beim sequentiellen Lesen trotz
höherer Bandbreite. Mein derzeitige Erklärung ist, dass der CFQ-I/O-
Scheduler I/Os zusammenfasste. Das tat er zwar auch, aber offenbar nicht in
sehr hohem Maß:
merge=216/761
Aber soweit ich das HOWTO verstehe, ist das die Anzahl der Merges und
macht keine Aussage, wieviele Requests der Scheduler zusammengefasst hat.
Anyway, das soll mal einen Einstieg bieten. Weitere Tests möchte ich erst
machen, wenn ich den fio-Entwickler mal zu meinem Workload befragt hab. Ob
ich so einigermaßen realistische Werte erhalten kann.
Also vorbehaltlich dessen, dass die Job-Datei einigermaßen Sinn ergibt,
frage ich mich schon, welche Festplatte auch nur *annähernd* auf diese
Werte kommt. Ich hab für Festplatten bislang keine Werte über 150 oder so
gesehen. Schnelle SAS-Platten mit 15000 RPM mögen etwas darüber hinaus
kommen, aber nicht viel. Das läßt sich ja anhand der Seek-Zeiten und der
Dauer für eine halbe Rotation schön ausrechnen, was physikalisch möglich
ist. Interessant zum Vergleich dazu mal die Latenzen der SSD ;). Für
zufälliges Lesen liegt diese überwiegend im Mikrosekunden-Bereich:
lat (usec): 2=77.54%, 4=21.11%, 10=1.19%,
Auch das dürfte so mit einer Festplatte nicht mal annähernd abbildbar
sein.
Getestet auf Intel SSD 320 mit Ext4, das auf einem LVM liegt. Also noch
nicht mal direkt auf dem Device. Für Lese-Tests mach ich mir denke ich
noch einen Job, der auf das komplette Device losgeht.
Sinnvoll wäre wahrscheinlich auch der Noop-Scheduler, aber angesichts der
Rechenleistung des Laptops spielt das wahrscheinlich auch keine Rolle
mehr, ob der Kernel jetzt die Requests etwas mehr oder weniger sortiert.
So, jetzt bin ich mal gespannt, ob mir jemand Meßwerte liefert, anstatt
einfach mal was durch die Gegend zu behaupten. Ich behalte mir vor,
weitere Pauschal-Behauptungen aka "Ich weiß es trotzdem besser", ohne das
wirklich zu überprüfen, einfach mal zu ignorieren. Denn das führt zu
nichts.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: