Re: SSD/Festplatten-Benchmarking (war: Re: [Semi OT] Suche neues Board für alte Hardware)
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.
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: