Schlechte Performance in RAID 0?

Hallo zusammen,

dies ist mein erster Beitrag, also Grüsse ich mal alle ganz herzlich

Nun, ich habe eine Frage:

Auf meinem Computer habe ich folgende Konfiguration:
- SAS-Kontroller Adaptec RAID 3805
- 6 Stück Fujitsu MAX3036RC, 36.7GB, 1500RPM

Ich habe die Geschwindigkeit der Platten mit HD Tach und h2benchw von heise online getestet.

Eine Platte bringt eine Leseleistung von ca. 90 MB/s.
Alle sechs Platten im RAID0 (StripeSize 256kb) bringen jedoch nur eine Leseleistung von ca. 260 MB/s.

Ich weiss es ist immer noch schnell. Ich finde es aber trotzdem komisch. Denn in der Theorie müsste ja die Leseleistung ca. 540 MB/s betragen. Ich bin mir bewusst, dass es weniger sein kann. Aber meine bringen eine Leistung von weniger als 50 % von der SOLL-Leistung.

Ich finde das Seltsam Hat jemand eine Ahnung warum das so ist?

Vieleicht noch zu meiner Systemkonfiguration:
- Mainboard: Intel D975XBX2KR (Bad Axe 2)
- CPU: QuadCore Extrem Edition QX6700, 2.66 GHZ
- RAM: 4 x 2GB Kingston HyperX DDR2 4GB Kit PC2-6400 (2x 2GB), 800MHz, CL5 (5-5-5-15), 240Pin
- Am 1. PCI-E-Slot (x16): ASUS EN8800GTX/HTDP/768MB RAM
- Am 2. PCI-E-Slot (x16, x8 electrisch): Adaptach 1220 SA mit 2 Seagate 400 GB im RAID1
- Am 3. PCI-E-Slot (x16, x4 electrisch): die oben erwähnte Konfiguration

Für Eure Antworten bin ich sehr dankbar

Gruss Roger.

@Tony85

Wie kommst Du denn darauf?

Habe ich gemacht. Hat nichts gebracht. Die Werte sind genau gleich.

Er hat einen Cache von 128 MB

Was soll eigentlich der Rechner mal machen?

PCIe x4 geht bis 1GB/s.

Trotzdem packen das die meisten Controller nicht. Hier mal was ähnliches:
http://www.tomshardware.com/de/Cha [...] 60-10.html

. 8 x Samsung SpinPoint T166, HD321KJ (320 GB) 7.200 RPM
. PCIe 4x Karte ARC-1220 von Areca bietet acht SATA/300 Ports, unterstützt Native Command Queuing (NCQ) und verfügt über 256 MB eingebauten DDR SDRAM Cache sowie eine Intel IOP333-Engine

Bis 4 Platten skaliert's beim Lesen linear hoch auf 320 MB/s. Ab der 5. Platte dann gedrosselt bei ca. 350MB/s.

Schreiben drosselt auch aber schon ab der 4-ten Platte bei 280MB/s.

4 x 2GB + 2 x 2GB = 10GB RAM, richtig?

Welches 64-Bit OS ist das denn?

Könntest mal kurz RAM rausziehen bist Du nur noch 2 GB hast. Dann nochmal Performance messen.

Denn was auch sein könnte: Dein Controller Treiber kann nur 32-Bit DMA Transfers und das OS kopiert nochmal in den höheren Adressraum.

Siehe
http://www.heise.de/ct/05/05/096/
vorletzter Absatz ("Fallstricke" ):

auf deutsch gesagt viel geld zum teufel und wenn mal eine platte kauputt ist alles wech bei 6 platten Oo

Nochmal meine Frage: Wozu soll das RAID-0 mit den 6 Platten genutzt werden?

Auf die Anwendung kommt es drauf an, ob Deine Config überhaupt sinnvoll ist.

In der Tat ist es beispielsweise so, dass die Zugriffszeit von 2 Platten mit 15.000 RPM im RAID-0 langsamer ist als die einer Platte mit 10.000 RPM. Allgemein nimmt die Zugriffszeit im RAID-0 mit zunehmender Plattenanzahl zu. Das ist Wahrscheinlichkeitsrechnung, weil bei vielen Platten die Wahrscheinlichkeit steigt, dass Daten auf einer Platte gerade unter dem Lesekopf durchgerutscht sind nachdem Du positioniert hast und Du eine Umdrehung warten musst bis Du sie bei einem Zugrifflesen kannst.

Der Tomshardwarelink oben beweist das Gegenteil:
2 Platten = 160MB/s
3 Platten = 240MB/s
4 Platten = 320MB/s

Erst ab der 5. Platte wird's bei der Controller Konfig von Tomshardware nicht-linear. Wer hat denn da in der Schule nicht aufgepasst?

Gut, wenn sich natürlich niemand die Mühe macht mal einen Link zu klicken. Dann muss ich wohl etwas ausführlicher zitieren, damit man die Problematik verstehst:

Von den technischen Daten sieht Dein Controller ja nicht schlecht aus. Würde mich auch wundern wenn er kein 64-Bit DMA kann und deshalb so lahm ist. Könnte man mit einem 32-Bit OS gegentesten, aber das hast z.Z. vermutlich nicht installiert.

Gibt's keinen Test von dem Controller?

Du wirst es auch nicht mit HDTach, HDTune etc. messen können. Diese lesen nur jeweils einen Sektor (512 Byte) und dann den nächsten irgendwo anders auf der Festplatte zufällig. Wenn man das so macht ändert sich an der Zugriffszeit überhaupt nichts.

Die Zugriffszeit verschlechtert sich, sobald über stripe size Grenzen gelesen wird. Also mehr als irgendwo zwischen 16kb - 64kb. Dazu muss von beiden Festplatten gelesen werden:

Zugriffszeit = Stroke/Seek Zeit + Latenzzeit

Letztere die Latenzzeit ist die Zeit die es dauert bis ein Sektor unter den Lesekopf rotiert. Im Schnitt dauert das eine Halbe Umdrehung. Bei einer 7200er Platte 4,17ms. Man kann es sich nun bildlich so vorstellen: Nach den 4,17ms hat die 1. Platte nun im Schnitt den Sektor gelesen. Die Zweite Platte hat ihren Sektor inzwischen entweder auch schon. Dann bleibt's bei den 4,17ms. Hat sie ihn nicht, dann dauert's länger.

Sei n die Anzahl der Platten. Dann ist diese Latenzzeit n/n+1 : U/min. Für eine einzelne 7200er Platte 4,17ms = 1/2 * 60s / 7200min. Bei einem RAID0 aus zwei solcher Festplatten kommt man auf 5,56ms. Addiere die durchschnittliche Strokezeit von 8,9ms Sekunden hinzu u. man kommt zum Ergebnis, dass die Zugriffszeit im Mittel von 13ms -> 14,5ms sich verschleichtert. Gute 10% schlechtere Zugriffszeit, wenn man von der gesamten Platte liest.

Ausführlicher hab ich's mal hier beschrieben:
http://toby.gmxhome.de/hardware/math_with_raid0.pdf

Bis hierhin vergehen 4,17ms bei einer 7200er Platte + die Strokezeit.

Das stimmt wie Du's schreibst. Blöd nur, dass bei einer Platte die 100MB/s liefert ein kompletter Stripe von 16kb - 64kb nach insgesamt 4,33ms - 4,82ms dann schon vorbei ist. Und jetzt kommt's eben drauf an ob die zweite Platte ihren Sektor dann schon gefunden hat. Beispiel ist in obigem PDF ausführlicher.

--

Noch interessanter als die theoretischen Überlegungen sind praktische Messwerte.

Anandtech hatte die langsamere Zugriffszeit dann auch mal nachgemessen:

http://www.anandtech.com/storage/s [...] i=2101&p=1

Allerdings sind die Level Daten (= Maps) im Laufe der Zeit auf viele hundert MB angeschwollen. Und je nach Game bringt RAID0 inzwischen doch minimal etwas:
http://anandtech.com/storage/showd [...] i=2974&p=5

Natürlich jedoch nicht für den Bootprozess von Windows. Die Zugriffszeit hat sich nach wie vor verschlechtert. Nur wird das von den großen Leveldaten bei Games kompensiert.

--

Richtig krass ist RAID1: Das verdoppelt die I/O Leistung, da Lese requests alternierend auf die Platten geschickt werden. RAID1 ist der Dual-Core der Festplatten.

Die Überlegungen zum RAID0 sind Controllerunabhängig. Das sind die in dem .pdf Dokument, die ich nochmals verkürzt hier wieder gegeben habe.

Beim RAID1 ist's etwas anders.

Ich hab' irgendwann mal aufgeschnappt, dass man beim RAID1 beide Lese-Requests gleichzeitig abfeuern könnte u. das Ergebnis der schnelleren Platte verwendet. Für eine 7200er Platte reduziert sich durch diese Maßnahme beim Random Access die durchschnittlich Zugriffszeit von 13ms auf 11,5ms. Die Mathematik ist wieder im .pdf letzte Section angedeutet. Bringt also ca. 10% Gewinn (theoretisch) bei dieser Sorte von Festplatten.

Viel größer ist jedoch der Gewinn, wenn ich die Kommandos nicht an beide RAID1 Festplatten gleichzeitig schicke, sondern nur an eine. Kommt ein weiteres Kommando während die 1. Festplatte im RAID1 beschäftigt ist, bekommt's die 2. Platte. Das ist das, was ich als "Verdoppelung" der I/O Leistung gemeint habe. Es gibt also zwei Optimierungsmaßnahmen. Die eine oben ist theoretischer Natur - zumindest im Moment. Die zweite findet sich in der Praxis wie man an diesem Bild erkennt, dass ich ja drüben im anderen RAID Thread schonmal gepostet habe:

http://blogs.zdnet.com/Ou/?p=484&page=3

An dem Bild sieht man auch mehr: Zum einen bei der Queutetiefe 1 gibt's keinen Unterschied. Ist auch klar, wenn immer nur 1 Kommando in der Pipe ist, das abgearbeitet werden will, dann greift die zuletzt beschriebenen Optimierung nicht. Es ist nichts da zum Verteilen auf andere Festplatten.

Ferner sieht man, dass sich eine "echte Verdopplung" natürlich nicht erreichen lässt. Zugriffe haben eben auch gewissen Lokalitätseigenschaften u. da greift diese Art der Optimierung nicht. Bzw. man muss Logik einbauen sie zu erkennen.

Wenn 3ware die zuerst beschriebene Optimierung einbauen wollte, müsste sie die Queuetiefe der Kommandos mit einbeziehen. Dabei muss ein gleitender Durchschnitt errechnet werden.

Ich wollte nach einen RAID0 und RAID1 Benchmark mit 3ware Controller schauen. Hab' aber nur RAID0 + RAID10 gefunden. Also hab' ich einen Controllertest genommen mit 'nem Acrea Controller RAID0 vs. RAID1 u. wollte dort mal die I/O Leistung vergleichen (um zu sehen, ob's so wie beim billigen Intel ist). Blöderweise ging das nicht, das Tomshardware so gemessen hat:

Dabei verkürzt sich die Stroke Distanz beim RAID0. Wenn man das hätte vergleichen wollen was ich meinte hätte das RAID0 entweder über die gesamte Platte gehen müssen oder doppelte Kapazität wie im RAID1. Ist sonst Äpfel u. Birnen.

Das ist auch nicht die Optimierung, die ich meinte. Deshalb hab' ich das eben nochmals ausführlicher geschrieben.

Soweit haben wir die gleiche Meinung.

Das das nicht so ist habe ich vorgerechnet. Konkret geht's darum, dass die Blöcke der ersten Festplatte je nach Stripe-Size nach 4,33ms - 4,82ms im Schnitt geliefert werden. Zusammen mit der 2. Platten ist aber die durchschnittliche Zugriffszeit 5,56ms. In der Zeit von 4,82ms - 5,56ms kann der Controller nichts sinnvolles machen.

Praxisbenchmarks, die diesen Effekt ausmessen hab' ich ja auch noch geliefert. Wobei Games dafür nicht die Killer-App sind, sondern eher Windows Booten.

Oder was ist mit Blocks gemeint? Wenn man 100MB kopiert, braucht man keine I/O Leistung. Wenn ich pro Zugriff 1ms einspare, sind das bei Zugriffen auf 500 Dateien schon eine halbe Sekunde. Es kommt halt drauf an was man macht. Windows Booten braucht mehrere kleinere Dateien. Und noch krasser ist Code kompilieren. Egal ob ich Linux Kernels oder Treiber kompiliere. Das sind tausende Dateien alle ziemlich klein. Skaliert prima auf Quadcore - der Flaschenhals ist I/O. Eclipse Entwicklungsumgebung musst ständig im Hintergrund für'n Syntaxcheck o. Refactoring kompilieren. I/O rulez.

--

Die Hersteller pennen im Moment allesamt: Eine SSD gehört als Inclusive Cache vor die Festplatten oder das RAID. Und zwar absolut flexibel: SSD kann entfernt u. hinzugefügt werden. Da inclusive Cache sind die Daten im Notfall immer auf Festplatte vorhanden. Selbst SSD Failure wegen Wearing stellt kein Problem da. Beim Schreiben muss jedoch eine Write Through Schreibstrategie angewendet werden. Copy-Back nur bei RAID Controllern mit RAM.

Das liefert im Moment keiner, obwohl Microsoft mit ReadyDrive noch am nähesten dran ist. Und OS Hersteller (Sun, Microsoft etc.) könnten nach ganz andere Optimierungen auf höherer Ebene bieten: pagefile, hibernate etc. ins Flash schieben. gibt nur partielle Lösungen bzw. Handwerk.

Ich geh' davon aus, dass 3ware aber diese I/O Optimierung für RAID1 implementiert hat. Habe bloß gestern nichts gefunden auf die schnelle.

HDTach, HD-Tune und Atto sind alle nicht recht geeignet. Denn z.B. bei der Zugriffszeit lesen die nur 1 Sektor u. da macht sich das mit den "schlechteren" Zugriffszeiten von RAID0 nicht bemerkbar.

Wenn man eines der vorangegangen Tools verwendet dann kann man das so beschreiben: Man vergleicht zwei Formel1 Autos. Das eine heißt RAID1 das andere RAID0. Wenn man diese beiden Formel1 Autos mit z.B: HDTach ausmisst, dann kommt da folgendes bei raus:

. Beschleunigung 0...200km/h : beide 5 sec (= Zugriffszeit)
. V_max : RAID1 = 300km/h; RAID0 = 500km/h (= max Durchsatz in MB/s)

Und die Frage die man beantworten will ist: Wer fährt die schnellere Rundenzeit auf dem Nürburgring? Was aber in den so gemessenen Zahlen nicht drin steht: Beide Kisten starten von der Start/Ziel Linie im Affentempo los. Das RAID0 Auto macht aber in der ersten Kurve nochmal eine Pause u. bremst runter auf 0 km/h (warum auch immer. Das ist eben die RAID0 Magic). Auf dem Nürburgring kann man V_max von 500 km/h eh nicht ausfahren u. so kommt's, dass RAID1 schneller ist obwohl alle meine technischen Daten (= synth. Benchmarks) vorher RAID0 für mindestens so toll wie RAID1 befunden haben.

Ich komm' gleich nochmal auf die Toolfrage u. wie das mit den kleinen Dateien ist.

Auf jeden Fall nur Quickformat.

iometer wäre wohl sinnvoll. Damit testen ja praktische alle (seriösen) HD bencher. Und da auch Deine Controller damit getestet wurden, denke ich, dass es da keine größeren Probleme gibt. Ich schau' gleich nochmal in die Doku vom iometer, aus dem Bauch raus würde ich vermuten, dass das Workstation wohl am besten die Arbeit eines Windows Benutzers am PC wiederspiegelt (mit allem Schnickschnack wie Virenkiller im Hintergrund etc.).

Wegen der Größe muss ich auch gerade mal überlegen. Klar ist, wenn man kleinere Größen nimmt, dann kriegt die Latenzzeit im Verhältnis Übergewicht zur Strokezeit. Editier' ich gleich mal was rein.

Nichts anderes sagt die Formel, die ich für die Latenzzeit angegeben habe:

n / (n +1) : U/min.

Mit 7200er Platte:
n = 1 (einzelne Platte) : 1 / 2 * 60 / 7200 = 4,17ms
n = 2 (RAID0 mit 2) : 5,56ms
n = 3 (RAID0 imt 3) : 6,25ms

Das steigt nur am Anfang um die guten 1,4ms. Später weniger. Und mit n -> unendlich konvergiert n / (n+1) -> 1 und das ganze dann gegen 8,33ms <= 2 * 4,17ms.

Entspricht genau der Realität: 1 Umdrehung bei einer 7200er Platte entspricht 8,33ms. Und wenn ich sehr viele RAID0 Platten verwende, dann haben die aber auch wirklich alle nach spätestens einer gesamten Umdrehung ihren 1 Sektor in der Hand.

Für's Testen heißt das: Ein RAID0 mit >2 Platten ist gar nicht so interessant. Zumindest nimmt das "Penalty" nicht mehr so stark zu. Und wenn durch große RAID0 die Strokezeiten noch verkleinert werden, da weniger weit in die Platte reingeseekt werden muss, wird das dadurch kompensiert.

Genauso wollte ich das auch verstanden haben: Übertragung geht los und dann legt die RAID0 Karre nach einer Weile noch mal ein kleines Päuschen ein. Und das sogar nicht immer, denn nur bei statistisch jeder zweiten Übertragung. Denn im anderen Fall hatte die 2. Platte den Sektor eh schon vor der 1. Platte u. war schon am Übertragen bevor Platte 1 überhaupt loslegt.

Soo viel braucht man da nich diskutieren. Dafür hab' ich schöeine Bildchen (geklaut):


Für's "normale" Arbeiten in Windows: Surfen, mailen, booten, Viruskiller im Hintergrund, was installieren.... spielen die kleinen Zugriffe eine Rolle. Nicht umsonst beschleunigen SSDs auch auch das Windows Booten so sehr. Beim Booten z.B. wenn alle Services + Autostart gleichzeitig abgefeuert werden. Die Platte ist da i/o mäßig am Ende.

Ich will Zugriffszeit natürlich nicht umdefinieren. Aber wenn's beim RAID0 hänger gibt u. die meßbar sind ... Kennst sicher auch die SSD Schreibhänger, weil der nur einzelne Flash-Seiten aktualisieren kann u. da teilweise nicht hinterherkommt. Erst recht wenn die Clustergröße nicht zur Flashseitengröße passt.

Genau das "Problem" von HDTune, die nur 1 Sektor lesen u. damit nicht sooo viele Schlüsse auf Anwendungsperformance zulassen. Mir gefiel früher das hdbenchw von c't gut. Das hatte auch so "Anwendungsprofile". Damit kann man messen, aber ich glaub' da war 'eine 40MB Schranke oder ähnliches drin - passt alles ggf. in RAM Caches heute. Bin da nicht update was hdbenchw angeht.

Ein Verkäufer wird dir nichts groß von Wearingstatistiken erzählen. Aber z.B. BBUs für Deinen RAID die gehören ja auch ausgewechselt. Zwar nicht die kleinen im 3ware, aber die großen in den Suns. Da gibt'sein Serviceintervall. Da bei SSDs die Entwicklung sich ohnehin überschlägt, der Performancegewinn aber so hoch ist, stell' ich mir das da genauso vor: Als Cachen kann man die SSD rausziehen wann immer man will. Sogar hot. Und jedes Jahr wird 'eine neue SSD (oder mehrere) reingewechselt. Lass' das EUR 1000,- pro Jahr kosten - das ist günstig. Bei den Sun-Geschichten darf das auch 5000,- pro Jahr für einen ganzen Paken von SSDs kosten. Das ist immernoch günstig.

Ich hab' kein Problem damit SSDs als Verschleißartikel zu sehen. Und dann ein paar "verschlissene" von Firmen abstauben ;-)

Ich glaub' fast das mit dem Benchen können wir uns auch schenken.

Hab' gerade ein bißchen geblättert. z.B. hier um so'n Office Testbed zusammenzu bekommen:
http://www.storagereview.com/Testbed4.sr?page=0%2C2
http://www.storagereview.com/artic [...] dBM_5.html

Und dann nochmal back-to-the-roots im RAID Verzeichnis von SR geblättert:
http://www.storagereview.com/guide/singleLevel0.html

Da geht's um independent reads im RAID0. Der testet ja nur solche 3ware etc. Controller. Also hat der 3ware das sicher im RAID0 u. im RAID1 sowieso.

EDIT: Also gegen einen 3ware braucht man beim RAID0 nicht gegen anzustinken:

http://www.xbitlabs.com/articles/s [...] 0se_9.html

Der liest völlig unabhängig von den Platten wenn's sein muss (Queuetiefe höher). Ein RAID0 läuft dort mit zwei Platten genauso schnell wie ein RAID1.

Was man aus RAID0 machen kann (-> 3ware) das wusst ich eben auch nicht.

RAID50 ist in dem Zusammenhang zwar auch interessant, aber man gibt ja wieder die zusätzliche Sicherheit von RAID6 auf. Und bei insgesamt 6 Platten muss man sich überlegen wie wahrscheinlich es ist, dass mal eine davon ausspringt u. ob man dann noch schlafen kann oder Mangels Backup ständig Datenverlust befürchten muss.

--

Iometer wurde ja lange nicht aktualisiert. Da gibt's sicher noch aktuellere. Allerdings werden die zum großen Teil eben kommerziell sein u. zumindest das Installieren einer ganzen Anwendungslandschaft (Adobe, Office etc.) voraussetzen. Schaue später nochmal was es außer Iometer gibt oder warum Iometer versagt bei den aktuellen Hardware RAIDs.

Das Atto etc. nicht funktionieren steht schon TH Test. Aber der Test mit IOMeter 2003.05.10 hatte dort ja geklappt.

Ich glaub' da brauchen wir jetzt mal 'einen größeren Versionsprung. Nimm mal iometer-2008.06.22-rc2:
http://sourceforge.net/project/sho [...] _id=634463

Da sind einfach zu viele Jahre dazwischen vergangen. Der muss doch gescheite Daten liefern. Im Changelog sehe ich unter anderem: "added speed step detection" sowie diverse Änderungen zu "CPU affinity". Genau die Probleme, die Du beschrieben hast.

--

Was mich auch schon länger gewundert hatte: Die Raptoren gehen ja in der Praxis gut ab. In den Benchmarks a la HDTune war das aber gar nicht unbedingt sooo ersichtlich. Beim Überfliegen von dem Testbed von StorageReview hab' ich aber noch was interessantes gefunden: Es geht um den kommerziellen Office DriveMark 2006, der die I/O Patterns von Anwendungen captured u. dann eben Festplatten/Controller mit diesem Zugriffsmuster benchen kann:
http://www.storagereview.com/Testbed4.sr?page=0%2C2
Dabei sind auch die Zugriffsmuster analysiert u. im Laufe der Zeit gab's eben eine Änderung für Office:

Das erklärt auch (teilweise) warum die schnell drehenden Platten (Raptor etc.) in der Praxis für's Systemvolume etc. so fantastisch geeignet sind.

--

Und beim Stöbern hab' ich noch was schönes gefunden HDTune : Win Server 2008 vs. Vista SP1 (unten):
http://www.techwarelabs.com/review [...] ex_6.shtml

P.S.: Dass der Thread inzwischen OT ist, ist ja nicht schlimm. Hatten wir ja schon öfters. Ist halt ein sketchboard.

Ich will mal 'einen bißchen über die I/Os schreiben, weil's 'eine Frechheit ist was 3ware da zum Testen fordert.

Als die NCQ-Blase damals geplatzt ist, haben sich ja auch die verschiedensten Leute Gedanken gemacht warum NCQ irgendwie nichts bringt. Ich müsste die Links jetzt aufwändig zusammensuchen, aber Ergebnis war: Im normalen oder selbst krassen Multitasking bewegt sich die outstanding I/O Queue Tiefe irgendwo zwischen 1-2. Man sieht das auch an dem oben bereits zitierten Desktop DriveMark 2006, dem Capturing von echten Windows Szenarien zu Grunde liegen:

http://www.storagereview.com/Testbed4.sr?page=0%2C2

Logisch ist: Wenn die Queuetiefe zumeist sogar nur 1 ist, kann NCQ nicht groß umsortieren.

Wenn man also iometer Diagramme lesen will, dann sind die Werte Q1, Q2, Q3 interessant. Danach ist das nur noch für Datenbanken interessant.

Schon nach Q8 steigen die Kurven nicht mehr groß, sondern sind eben schon mehr oder weniger konvergiert. Deine Beobachtung, dass nach Q8 nicht mehr groß etwas passiert ist so völlig korrekt. Was passiert jetzt wenn 3ware gerne bei Q256 Testen möchte? Deren IO Prozessoren haben immer genug zu fressen u. können die I/O Listen (256 Einträge) so umsortieren, dass eine möglichst hoher I/O Durchsatz dabei herauskommt. Im iometer steigt der i/o durchsatz von Q8 -> Q256 nochmal von 5519 -> 5707. Nicht viel, aber wenn man als Hersteller daran interessiert ist eine möglichst hohe i/o Zahl auf dem Papier zu haben, dann kann man das so machen.

Es hat jedoch einen gravierenden Nachteil: Vergleicht man mal die average Latency in den zwei Screenshots dann verschlechtert diese sich von 1,45ms -> 44,96ms. Auch wenn diese Werte großen Schwankungen unterliegen sollten. Jeder Request muss sich hinten an der Schlange anstellen. Einzelne werden nach vorn geholt / umsortiert, aber die durchschnittliche Latenzzeit ist mieserabel.

So ein System ist in der Praxis absolut untauglich. Wenn man auf eine Datenbank zugreifen muss, dessen I/O Queuetiefe so lang ist oder ein Multiuser-Filesystem, dann wartet man ewig. Das Ding ist grottenlangsam. Wenn man ein solches System vorfinden würde, müsste man sofort das I/O System austauschen (schnellere Platten, mehr Platten etc.) um die I/O Latenz zu senken.

Leider hat der andere Typ, den ich jetzt leider schon zum 3. Mal zitiere ja keine absoluten Zahlen für die I/O Tiefen genannt, die bei Datenbanken naturgemäß höher sind, aber immerhin:

http://blogs.zdnet.com/Ou/?p=484&page=2
Ob man auf eine SQL Anfrage nun 0,2s oder 0,6s warten muss, das merkt man im interaktiven Betrieb. Erfordert eine GUI Abfrage sogar mehrere SQL Abfragen im Hintergrund multipliziert sich das entsprechend aus.

--

Will man für Desktop Anwendungsfälle aus iometer Diagrammen etwas herauslesen und RAID Varianten (RAID0, RAID1, RAID5, RAID50) vergleichen, muss man schauen wie sich die bei Q1, Q2, Q3 verhalten. Das Konvergenzverhalten ist wieder auch nicht soooo interessant. Das alles auszutesten brauchen wir nicht.

Aber wenn Du magst: Mach' mal noch ein Q2 dazu. Und dann wenn Du das RAID6 einrichtest nochmal diese zahlen dazu: Q1, Q2, Q8.

So, dann mal ein bißchen Auswertung.

IO/s Auswertung (klick für groß):

MB/s Auswertung (klick für groß):

Zu den graphischen Darstellungen:
. Die unterschiedlichen Konfigurationen (balanced, protection) konnte ich nicht alle beschriften. Der Unterschied liegt aber vor allem im Write Speed, der hier ja eh nicht getestet wurde.
. Dass die X-Achse 1,2,3,8,256 beschriftet ist so jetzt nicht großartig logarithmisch sein, aber nachdem was wir hier in dem Thread diskutiert haben ist vor allem der vordere Teil der Kurven interessant.
. Die tabellarischen Daten jeweils darüber, um auch für dicht bei einander liegenden Werten Details ausmachen zu können.

Auswertung:
Es ist nicht weiter überraschend, dass die Kurven im von IO/s und MB/s gleichartig verlaufen. Denn wenn ich keine IO/s hab' kann ich auch nichts übertragen.

Was schon etwas überrascht: Das RAID-6 ist quasi genauso schnell wie das RAID-50. Letzteres ist wohl nicht ganz so optimal implementiert, denn das RAID-50 sollte ja ein paar theoretische Vorteile bieten wie in diesem Thread bereits diskutiert. Wenn man andere IOmeter Diagramme beim 3ware mit dazu nimmt, dann kommt da Speedmäßig wohl raus: RAID-50 <= RAID-6 < RAID-5.

Ghostrider: Sicher testest Du doch noch, ob das Degraden + Rebuild so klappt wie Du Dir das vorstellst. Da reisst doch sicher nochmal 1-2 Platten aus dem RAID-6. Könntest Du mit diesen beiden Platten doch noch ein 2. Array anlegen u. Testen:
. einzelne Platte (als Referenz)
. RAID-1
. wenn möglich noch für's RAID-0 ein paar tieferliegende Q1 IO/s.
Falls Du degrade/rebuild beim RAID-6 nicht testest: RAID löschen u. neuanlegen geht natürlich schneller.