Test Pattern für IOMeter

Allein die Workloads reichen nicht aus. Du mußt dann auch noch ein paar andere Details einstellen (# outstanding IOs, Anzeigeintervall der Messwerte, etc).
Streaming Reads und Writes sind einfach selbst zu erzeugen:

64k Blocks, 100% Read (oder eben Write), 100% sequential nichts bei Burst oder soetwas verändern.

MB/s und IOs/s werden Dir immer gleichzeitig angezeigt und sich hochgradig von solchen Fakturen wie "outstanding IOs", der Blockgröße, etc abhängig.

Wenn die Blockgröße zu groß gewählt wird (z.B. 8MB), dann geht vielleicht die Transferrate MINIMAL nach oben, dafür hast Du unglaublich schlechte Zugriffszeiten und dementsprechend niedrige IO-Raten.

64K ist schon nur noch für eine "best-case", also wirklich "sequential read/write"-Abschätzung zu gebrauchen.

Noch was: Benutze am besten die aktuelle "beta" Version. Die alten (2006) sind für viele aktuelle Systeme und RAID-Controller ungeeignet und produzieren nur SCHROTT. Negative-Zugriffszeiten etc sind bei den alten Versionen keine Seltenheit.

Hier habe ich sie Dir mal hingelegt: http://www.derghostrider.de/photos/wrkloads.zip


Falls Fragen auftreten sollte, einfach schreiben.

Guter Link. Die 2008-06-22 meinte ich auch.

200000 Blöcke entsprechen nur ca 100MB (200000 x 512Byte). Dort solltest Du eine Testgröße von locker 4GB einstellen. Vorher mußt Du die bereits angelegten Testdateien wieder löschen, sonst werden die nicht angepasst.

Den Schieberegler könntest Du einfach mal auf 5s stellen. Ab "3s" kommen ganz brauchbar gemittelte Werte raus. Davor sollte allerdings "Last Update" und nicht "Star of Test" angewählt sein. Am Anfang braucht der Test manchmal ein oder zwei Sekunden, bis er ein anständiges Ergebnis ausspuckt und daher ist die zweite Option besser.

Also:

- Sectors: ca 8Mio einstellen.
- "Last Update"
- 5s
Einen Moment warten und ein paar der Werte miteinander vergleichen.

Wichtig ist auch immer die Angabe der "Outstanding IOs", die Du ganz am Anfang mit den "Sectors" angeben kannst. Bei 1 Outstanding IOs dürften die Werte schlechter ausfallen, ab 8 sollten die Werte recht gut gut sein.
Aber: In einer "normalen" DESKTOP-Umgebung hat man einen Schnitt von 1,x IOs in der Warteschlange. Wesentlich höhere Werte sind also ehr für Server interessant oder eben um herauszufinden, was der Controller mit den Platten maximal schaffen kann. Mit der Realität hat das dann im Heimgebrauch weniger zu tun.

BTW: Warum sind Deine Screenshots alle so grün?

@MeriStar:
Bei den Outstanding IOs ist der "passende" Wert derjenige, der zu Deinem speziellen Zugriffsmuster (also zu diesem speziellen Server) passt. Die Queue-Lenge der noch nicht abgearbeiteten Anfragen ist speziell von der Verwendung abhängig.
Während man bei Desktop-Systemen im Schnitt z.B. 1.x outstanding IOs hat (irgendwo zwischen 1,3 und 1,6), kann es bei Servern, in Abhängigkeit der User und Anfragen, natürlich deutlich nach oben abweichen.
Tools, die die IO-Queue-Length bestimmen sind mir leider nicht bekannt. Vielleicht hilft Google weiter...

Bezüglich des RAMs: Es wird immer empfohlen eine Testfile-Größe zu verwenden, die größer ist als RAM + Cache. ... bei IOmeter muß ich sagen, daß es recht unempfindlich diesbezüglich ist. Man sollte auf jeden Fall eine Testdatei anlegen lassen, die "ein Vielfaches der Datenübertragungsrate pro Sekunde" beträgt.
Gemeint damit ist: wenn das RAID z.B. 500MB/s schafft, dann sollte die Test-Datei mindestens (absolute Untergrenze, ehr nicht empfehlenswert) 1GB groß sein. Ich würde in einem solchen Fall eher zu 4GB bis 8GB Raten.
16GB als Testdatei sind ja auch nicht sonderlich Problematisch. Die RAID-Systeme haben heute doch alle deutlich mehr Platz zur Verfügung und bei den heutigen Platten dauert das Anlegen auch nur "einige Sekunden". 80Mio Sektoren sollten zu ca. 40GB Testfilesize führen (Basis 10, nicht Basis 2 - also 40.000.000.000 Byte). Das müsste in jedem Fall dicke ausreichen und Du bist auf der sicheren Seite Dich nicht selbst hereingelegt zu haben.

Wenn Du bereits einen Fileserver hast, dann kannst Du auch mit diversen Tools die Dateigrößenverteilung feststellen und dafür selbst passende Testpattern anlegen, die Deinem Datenbestand entsprechen.
Allerdings solltest Du dafür nicht nur wissen, wie groß die Dateien sind, sondern auch, wie häufig auf welche dieser Größenklassen zugegriffen wird.
Es hilft ja nichts, wenn, aus welchem Grund auch immer, Millionen von Dateien unter 1kB herumliegen, diese aber alle aus einem Projekt stammen, welches bereits seit einem Jahr nicht mehr angefasst wird, im Benchmark dann aber überwiegend getestet wird, da es eben unheimlich viele Dateien sind.

Mit den Workern habe ich mich zugegebener Weise noch nie genauer befasst. Das entscheidende dabei ist aber wohl, daß unterschiedliche Zugriffsarten parallel getestet werden können.
Eben der eine Worker, der immer in Datenbanken rumwuselt und Haufenweise kleine Schreib- und Lesezugriffe rausfeuert, während ein unabhängiger anderer Worker nur "größere" Dateien simuliert bearbeitet (streaming Read & Write - Ablegen von Images, sichern von VMs von Arbeitsplatzrechnern, Sicherungsjobs, etc).
So DENKE ich es mir zumindest.

Das Handbuch erklärt auch einige Szenarien (der erste Link):
http://www.iometer.org/doc/documents.html

Im Grunde steht es dort so beschrieben, daß jeder Worker ein neuer Thread ist, der ein Testszenario abarbeitet.

Unter Punkt 9.4 ist eine Erklärung zu "# outstanding IOs" gegeben.