Re: SSD/Festplatten-Benchmarking (war: Re: [Semi OT] Suche neues Board für alte Hardware)

[Martin Steigerwald <Martin@lichtvoll.de>]

Am Freitag, 29. Juli 2011 schrieb Martin Steigerwald:
> Am Freitag, 29. Juli 2011 schrieb Martin Steigerwald:
> > 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:
> [...]
> 
> > Ü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ß:
> Bezüglich des Verhältnisses von zufälligem versus sequentiellen Lesen
> habe ich über die fio-Mailingliste noch eine Frage offen, denn ein
> einfacherer Lese-Workload liefert für zufälliges Lesen mit nur 6000
> IOPS deutlich geringere Werte.

Gelöst... Kurze Zusammenfassung einer längeren Odysee: Es fehlt in der 
Job-Datei für den letzten Job die Option "stonewall":

martin@merkaba:~[...]> diff -u iops.job iops-done-right.job 
--- iops.job    2011-07-29 16:40:41.776809061 +0200
+++ iops-done-right.job 2011-08-02 16:15:06.055626894 +0200
@@ -19,4 +19,5 @@
 stonewall
 [sequentielllesen]
 rw=read
+stonewall

Damits gibts dann realistischere Werte:

zufälliglesen: (groupid=2, jobs=1): err= 0: pid=20484
  read : io=2048.0MB, bw=23151KB/s, iops=7050 , runt= 90584msec
    clat (usec): min=0 , max=70235 , avg=134.92, stdev=212.70
     lat (usec): min=0 , max=70236 , avg=135.16, stdev=212.79
    bw (KB/s) : min=    5, max=118959, per=100.36%, avg=23233.61, 
stdev=12885.69
  cpu          : usr=4.55%, sys=13.30%, ctx=259109, majf=0, minf=27
  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=638666/0/0, short=0/0/0
     lat (usec): 2=21.65%, 4=30.12%, 10=7.42%, 20=0.69%, 50=0.06%
     lat (usec): 100=0.01%, 250=14.58%, 500=21.58%, 750=3.85%, 1000=0.01%
     lat (msec): 2=0.02%, 4=0.01%, 10=0.01%, 20=0.01%, 50=0.01%
     lat (msec): 100=0.01%

Was immer noch sehr schnell ist für zufälliges Lesen mit 2-16 KB 
Blockgrößen.

Nun, die Werte für die genausoschnellen SAS-Platten stehen ja ohnehin noch 
aus. Wenn dann aber besser mit der gefixten Job-Datei.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7