Modell | Intel X25-E SSD | 32 GByte |
Mainboard | Gigabyte X38-DQ6 | |
Chipsatz | Intel X38 | 1066 MHz |
CPU | Intel Xeon 3060 | 2.4 GHz |
Speicher | Corsair Dominator 9136 DDR2 | 2 GByte |
Grafikkarte | Gigabyte GeForce 7200 | |
Storage (System) | Maxtor | 160 GByte |
Betriebssysteme | Ubuntu 8.04.1 Hardy | Kernel 2.6.24-19-server |
Dateisystem | XFS |
Wer kennt das nicht? Man kauft sich eine Festplatte, die gemäss Spezifikationen 120 MB/s lesen soll, in den Reviews ca. 110 MB/s effektiv liefert und, sobald eingebaut, viel langsamer wirkt, als alle behauptet haben. Führt man selbst einen Test durch und kommt zu der Stelle, an der 4 KByte-Blöcke zufällig geschrieben werden, sinkt die Datenrate nicht selten auf 2 - 3 MB/s.
Wir haben uns daher entschieden, nicht die üblichen Screenshots von Testprogrammen zu liefern, sondern die Tests so durchzuführen, dass sie
sind.
Getestet wird grundsätzlich mit Verwendung von Caches und NCQ (diese sind im täglichen Gebrauch auch aktiviert). Die zu schreibenden Datenmengen übersteigen aber immer den im System vorhandenen Arbeitsspeicher um mindestens das Doppelte.
Aufgefallen ist, dass sich der Messfehler konstant bei etwa ±2% bewegt, bei allen Tests. Deshalb wird dieser auch nicht überall angegeben. Bei den angegebenen Testwerten handelt es sich um Durchschnittswerte.
Datenbanken hängen fundamental vom benutzten Speichersystem ab. Mit der richtigen Wahl des Speichersystems kann die Performance von Datenbanken auf einer konventionellen Festplatte deutlich gesteigert werden. Um dies aufzuzeigen benutzen wir PostgreSQL in der Verison 8.3.3 in Kombination mit dem Script pgbench.
Wir werten nach dem Test zusätzlich die S.M.A.R.T. Daten aus, um festzustellen, ob bereits Fehler gemeldet wurden und welche Informationen überhaupt gesammelt werden.
Folgende Tabelle fasst zusammen, vorauf wir bei den Tests unser Augenmerk legen:
Test | Beobachtungen |
Sequential Read/Write Tests |
|
Random Read/Write Tests |
|
Es gibt verschiedene Gründe, warum für den Test ein Betriebssystem mit Linux-Kernel verwendet wird, statt des klassischen, frisch installierten Windows XP mit allen Service Packs:
Das Dateisystem wurde folgendermassen erstellt:
mkfs.xfs -f -d sunit=128 -d swidth=4096 /dev/sdbGemountet wurde mit den Optionen:
mount -o rw,noatime,logbufs=8 /dev/sdb /mnt/ssdDer Durchsatz wird mit den folgenden Parametern ermittelt:
iozone -Rb test_xk.out -i0 -i1 -i2 -+n -r xk -s4g -t2Die Operationen pro Sekunde werden mit den folgenden Parametern ermittelt:
iozone -Rb test_xk.out -i0 -i1 -i2 -+n -r xk -s4g -t2 -ODas "x" steht jeweils für die Blockgrösse in KByte.
Es ist wichtig, die alltagsnahen Szenarien bei einem Test zu reproduzieren. Gewisse Parameter müssen während der Tests variabel sein, damit eine Aussage über das Produkt gemacht werden kann. In unserem Test ist dies die Blockgrösse. Sie bestimmt die Grösse in KB an Daten, die pro Transaktion auf das Drive geschrieben oder davon gelesen werden.
Damit kann man das Lesen und Schreiben von kleinen und grossen Dateien testen. Kleinere Files als 16 KB kommen im Desktop-Bereich eher selten vor. Mailserver und Datenbankserver haben aber einen viel grösseren Anteil an kleinen Dateien. Somit ist besonders bei Datenbanken ein Test mit kleinen Blockgrössen interessant, da die Datenbank nach jeder beendeten Transaktion die Daten sofort auf die Platte speichert (damit garantiert ist, dass alles wie beabsichtigt gespeichert wurde — auch nach einem Stromausfall).
Bei grösseren RAID-Verbünden ist der Festplatten-Cache normalerweise deaktiviert. Stattdessen übernehmen die RAID-Controller die Caching-Arbeit. Gerade in solchen Setups müssen Festplatten bezüglich kleinen Datenmengen trumpfen können. Sequentieller Durchsatz ist fast nicht von Bedeutung.
Navigate through the articles | |
Samsung Spinpoint F1 1.0 TByte | OCZ Apex 120 GByte MLC SSD |
|