Wie testen wir?

Testumgebung

Lesern, die sich nicht intensiv mit Aufbau und Überlegungen bezüglich Testverfahren auseinander setzen möchten, empfehlen wir die folgenden zwei Seiten zu überspringen und direkt zu den Testresultaten zu springen.

Testresultate

Modell	Intel® X25-M Mainstream SATA Solid-State Drive	80 GB (74 GiB effektiv)
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 Microsoft Windows XP	Kernel 2.6.24-19-server SP3
Dateisystem	XFS
Datenbank-Management-System	PostgreSQL	Version 8.3.3

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

• reproduzierbar,
• akkurat,
• aussagekräftig und
• vielseitig

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. Normalerweise sind moderne DBMS auf Festplatten optimiert und nicht auf SSDs. Mit der richtigen Wahl des Speichersystems kann die Performance von Datenbanken somit auf einer konventionellen Festplatte deutlich gesteigert werden. Interessant ist es nun festzustellen wie sich das SSD unter diesen Bedinungen verhält. 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	Werden die angegebenen Werte (Spezifikationen) wirklich erreicht? Welchen Einfluss hat die Blockgrösse? Welchen Einfluss hat die Blockgrösse des Dateisystems?
Random Read/Write Tests	Wie stark ist der Einfluss auf die tdeoretisch mögliche (sequentielle) Datenrate? Welchen Einfluss hat die Blockgrösse? Welchen Einfluss hat die Blockgrösse des Dateisystems?
Datenbank-Tests	Wieviele Transaktionen pro Sekunde (TPS) kann die Datenbank liefern? Bleibt die Geschwindigkeit (TPS) konstant, wenn sehr viele Anfragen gleichzeitig an die Datenbank gestellt werden? Wie stark wird die CPU belastet?

Linux, XFS, wieso?

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 (XFS) lässt sich wesentlich flexibler konfigurieren als das proprietäre NTFS.
• Das verwendete Testprogramm iozone läuft unter Linux nativ und es lassen sich vielfältigere Arten des Zugriffs auf das Drive einsetzen.
• Der Test zielt unter anderem auf die Verwendung im Server-Bereich ab.
• Das gewählte Testprogramm liefert Daten auf statistischer Basis (Fehler, Varianz, etc.)

Trotzdem möchten wir unsere subjektiven Erfahrungen unter Windows XP in diesem Test einbringen: Boot-Zeit, Starten von Programmen und Entpacken von Dateien.

Das Dateisystem wurde folgendermassen erstellt:

mkfs.xfs -d sunit=128 -d swidth=4096 -l size=128m -f /dev/sdb

Gemountet wurde mit den Optionen:

mount -o rw,noatime,nousrquota,logbufs=8 /dev/sdb /mnt/ssd

Wieso werden verschiedene Blockgrössen getestet?

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 ist 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.

Kleinere Datenblöcke sind ausserdem bei diesem SSD viel interessanter, weil der Durchsatz mit grossen Blöcken/Dateien (Videobearbeitung) ohnehin gegeben und vor allem konstant ist — aber nun zu den Resultaten:

Datenbanktests

Setup

Über das Script pgbench lässt sich eine Datenbank mit zehn Millionen Einträgen erstellen. Danach werden diese Daten auf verschiedene Arten ausgelesen, verändert und wieder zurückgeschrieben. Das ist zugegebenermassen ein einfacher Test, dennoch hebt er den Unterschied zwischen SSDs und konventionellen Festplatten hervor.

Die ganze Transaktion sieht folgendermassen aus:

• BEGIN;
• UPDATE accounts SET abalance = abalance + :delta WHERE aid = :aid;
• SELECT abalance FROM accounts WHERE aid = :aid;
• UPDATE tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
• UPDATE branches SET bbalance = bbalance + :delta WHERE bid = :bid;
• INSERT INTO history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
• END;

Der Test wird durchgeführt mit den Standard-Eintellungen von PostgreSQL. Damit die Datenbank auch wirklich auf dem SSD erstellt wird, müssen wir einen Tablespace anlegen und das bei der Erstellung so mitteilen:

CREATE TABLESPACE ssdbench LOCATION '/mnt/ssd/tablespace';
createdb -D ssdbench pgbench

Danach muss die Datenbank gefüllt werden:

pgbench -i -s 100 pgbench

Dadurch fügen wir zehn Millionen Tupel in die eben erstellte Datenbank ein. Jetzt wird das Script gestartet, das 10000 Transaktionen mit 100 Connections erstellt. Es geht darum, die Pipeline mit Transaktionen zu füllen, deshalb wird die sehr hohe Anzahl Transaktionen gewählt:

pgbench -n -t 10000 -v -c 100 pgbench

Danach erhalten wir ein Resultat in Transaktionen pro Sekunde (tps):

transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 100
number of transactions per client: 10000
number of transactions actually processed: 1000000/1000000
tps = 1344.524649 (including connections establishing)
tps = 1344.802165 (excluding connections establishing)

Artikel im Forum diskutieren