Serverloft XXL RAID-Performance

D

dexter

New Member
Gudnaabend,

irgendjemand hier hat doch bestimmt einen Serverloft XXL zur Hand... und 5 Minuten Zeit, folgende Benchmarks zu fahren :rolleyes:

Code: 
mkdir /home/dbench
dbench -D /home/dbench -t 60 2
dbench -D /home/dbench -t 60 4
dbench -D /home/dbench -t 60 6
dbench -D /home/dbench -t 60 8
dbench -D /home/dbench -t 60 10

Hier die Ergebnisse von meinem Serverloft XL (RAID 1):

Code: 
Throughput 337.191 MB/sec 2 procs
Throughput 627.613 MB/sec 4 procs
Throughput 801.643 MB/sec 6 procs
Throughput 789.673 MB/sec 8 procs
Throughput 506.82 MB/sec 10 procs

Das ist mit 60 Sekunden Laufzeit zwar keine wissenschaftlich genaue Analyse aber genügt um ein Bild der Performance des RAID-Controllers zu bekommen.

Bei RAID 1 (XL) sind diese Werte im Vergleich sehr gut.

Mich interessiert nun, ob der ZCR-Controller im XXL genügend Performance für 8 Cores auslastende Datenbankanwendungen liefert.

Thanks!
 
XXL:
Code: 
Throughput 370.864 MB/sec 2 procs
Throughput 623.107 MB/sec 4 procs
Throughput 753.089 MB/sec 6 procs
Throughput 807.619 MB/sec 8 procs
Throughput 697.661 MB/sec 10 procs

L:
Code: 
Throughput 386.391 MB/sec 2 procs
Throughput 576.093 MB/sec 4 procs
Throughput 708.381 MB/sec 6 procs
Throughput 706.547 MB/sec 8 procs
Throughput 713.336 MB/sec 10 procs
 
Dankeschön!

Kleine Rückfrage: Ist der XXL out-of-the-box, sprich sind das die Werte für RAID 5?

Dann wäre der Durchsatz mit RAID 5 mindestens so gut wie mit RAID 1... sprich: Keine Nachteile durch RAID 5 auch bei stark schreiblastigen Datenbank-Operationen...
 
Hallo!

Sehr interessanter Thread!

Ich habe nun auch mal dbench 4.0 auf meinem XXL mit RAID1 und HotSpare unter CentOS 5 x64 kompiliert und ausgeführt:
Code: 
XXL:
Throughput 13.3091 MB/sec  2 clients  2 procs  max_latency=510.838 ms
Throughput 16.7968 MB/sec  4 clients  4 procs  max_latency=1225.460 ms
Throughput 17.2672 MB/sec  6 clients  6 procs  max_latency=11031.171 ms
Throughput 15.9222 MB/sec  8 clients  8 procs  max_latency=14968.774 ms
Throughput 15.4229 MB/sec  10 clients  10 procs  max_latency=20228.312 ms

Warum hab ich denn da so extrem schlechte Werte?
Habt ihr bei der Config von dbench was spezielles gemacht oder so (kein standard client-file, etc.)?

Auf dem Server läuft zwar MySQL, etc., ist aber alles noch idle, d.h. keine Tabellen oder so was drauf... Auch sonst hat der Server nix zu tun weil er derzeit als Backup-Not-Server dient...

Wäre super wenn wir das klären könnten ;-)

Danke und viele Grüße,

Chris
 
Hi Chris,

ich habe nichts besonderes bei dbench eingestellt (Aufruf wie oben angegeben). Ich habe die Standardversion aus dem SuSE-Repository genommen, das ist eine V3.04.

Latenzen von 20 Sekunden (!) kommen mir aber auch reichlich spanisch vor. Sicher, daß beim kompilieren alles korrekt konfiguriert war?

Du hast also Deinen XXL auf RAID1 umkonfiguriert (vermutlich auch aus RAID5-Performancesorgen?) -- ging das problemlos per BIOS-Konsole?

Dexter
 
Hey :-)

Ja also beim Kompilieren ist mir nichts aufgefallen...
Man kommt ja leider nicht selbst ins RAID-Menü, deswegen hat die Technik von SL für mich ein RAID1 mit HotSpare eingestellt.
Richtig, ich habe das sowohl auf Grund von Geschwindigkeitsgründen, als
auch Sicherheitsgründen gemacht.
Denn wenn Dir bei RAID5 zwei Platten ausfallen ist das ganze RAID hin.
Bei meinem Setup können (außer wenn es gerade beim Rebuild passiert) zwei Platten ausfallen und die Daten sind noch da ;-)
Finde daher ein RAID5 mit nur drei Platten nicht sehr sinnvoll ;-)

Aber zurück zum Performance-Problem:
Wir sind kurz davor den Server wirklich "live" zu verwenden und ich bin nun doch etwas beunruhigt ob der wohl anscheinend schlechten Performance :-(

Was könnte ich denn da noch testen?

Vielen lieben Dank für jegliche Hilfe :-)

Liebe Grüße,

Chris
 
Habt ihr die Ergebnisse eigentlich mal auf Plausibilität überprüft?

Bei Datenraten von 300-700MB/sek fragt man sich doch eigentlich, wie das gehen soll. SAS, UW-SCSI-320 und SATA-300 sind alle schon vom Interface her nicht in der Lage - mal abgesehen davon, dass die Platten das erstmal wuppen müssen. Und für cached reads/writes ist das viel zu wenig.
 
Last edited by a moderator:
Hi Chris,

zwecks Vergleichbarkeit hab ich jetzt auch dbench 4 kompiliert und durchlaufen lassen. Die Resultate verschiedener Versionen sind nicht direkt vergleichbar.

Hier also meine dbench4-Werte für den XL bei marginaler sonstiger Last (load < 0,1):

Code: 
Throughput 46.4158 MB/sec  2 clients  2 procs  max_latency=531.101 ms
Throughput 44.1461 MB/sec  4 clients  4 procs  max_latency=1094.270 ms
Throughput 44.2061 MB/sec  6 clients  6 procs  max_latency=1053.456 ms
Throughput 40.802 MB/sec  8 clients  8 procs  max_latency=1238.836 ms
Throughput 41.7225 MB/sec  10 clients  10 procs  max_latency=2018.841 ms

Spannend.

Hier die Werte von meinem 1&1 3XL (Hardware RAID 1), bei sonstigem Load um 1,0:

Code: 
Throughput 218.069 MB/sec  2 clients  2 procs  max_latency=82.394 ms
Throughput 265.28 MB/sec  4 clients  4 procs  max_latency=5228.514 ms
Throughput 272.215 MB/sec  6 clients  6 procs  max_latency=2697.767 ms
Throughput 269.564 MB/sec  8 clients  8 procs  max_latency=3387.253 ms
Throughput 240.496 MB/sec  10 clients  10 procs  max_latency=4173.982 ms

...und von meinem 1&1 4XL (Hardware RAID 5), sonstiges Load zwischen 1 und 2:

Code: 
Throughput 137.938 MB/sec  2 clients  2 procs  max_latency=3647.212 ms
Throughput 125.774 MB/sec  4 clients  4 procs  max_latency=7031.787 ms
Throughput 156.205 MB/sec  6 clients  6 procs  max_latency=4407.295 ms
Throughput 96.3197 MB/sec  8 clients  8 procs  max_latency=10737.656 ms

Die Schwankungen sind mit dem stark schwankenden sonstigen Load zu erklären, eigentlich sollte man solche Tests nur bei unbelasteter Kiste fahren. Trotzdem ergibt sich insgesamt ein Bild, und Deine Werte fallen hier total aus dem Rahmen.

Sag mal... hast Du eigentlich die üblichen Tuningmassnahmen an deinem XXL vorgenommen? Will sagen vor allem den Write Cache der Platten aktiviert, außerdem ggf. den pollenden kipmi-Prozess gebändigt und APIC (für die IRQ-zu-Core-Verteilung) aktiviert?

Dexter
 
elias5000 said:
Habt ihr die Ergebnisse eigentlich mal auf Plausibilität überprüft?
Click to expand...

Guter Hinweis. Bislang ging's mir in erster Linie um Vergleichbarkeit. Ich dachte bei den "MB" handelt es sich wohl um MBit, die Doku sagt aber doch was anderes.

"There are lies, damn lies and benchmarks..."

Ok, anderer Ansatz: dbench kann mit "-s -S" synchron arbeiten. Damit müssten sich Filesystem-Cache-Effekte minimieren lassen.

Hier also die Werte von meinem Serverloft XL mit synchroner I/O:

Code: 
Throughput 10.0232 MB/sec (sync open) (sync dirs)  1 clients  1 procs  max_latency=1018.668 ms
Throughput 10.8964 MB/sec (sync open) (sync dirs)  4 clients  4 procs  max_latency=1314.259 ms
Throughput 17.5091 MB/sec (sync open) (sync dirs)  6 clients  6 procs  max_latency=873.402 ms
Throughput 18.2477 MB/sec (sync open) (sync dirs)  8 clients  8 procs  max_latency=464.335 ms
Throughput 19.6883 MB/sec (sync open) (sync dirs)  10 clients  10 procs  max_latency=1648.345 ms
Throughput 18.6471 MB/sec (sync open) (sync dirs)  12 clients  12 procs  max_latency=1108.263 ms
Throughput 15.1326 MB/sec (sync open) (sync dirs)  16 clients  16 procs  max_latency=2121.040 ms
Throughput 13.2617 MB/sec (sync open) (sync dirs)  20 clients  20 procs  max_latency=2895.844 ms

...da die nun ziemlich nah an denen von Chris liegen würde ich vermuten, daß der Unterschied tatsächlich am Cache lag und diese Werte eher die reelle Hardwareperformance wiedergeben.

Chris, hast Du evtl. den Cache aus oder mountest Du das Filesystem mit Option "sync"?
 
Hey Dexter!

Sorry für meine späte Antwort, ich war gestern unterwegs..
Also ich denke der WriteCache ist schon an:
Code: 
[root@cluster1 MegaCli]# ./MegaCli64  -LDInfo -Lall -aALL
Adapter 0 -- Virtual Drive Information:
Virtual Disk: 0 (target id: 0)
Name:
RAID Level: Primary-1, Secondary-0, RAID Level Qualifier-0
Size:476416MB
State: Optimal
Stripe Size: 64kB
Number Of Drives:2
Span Depth:1
Default Cache Policy: WriteThrough, ReadAhead, Cached, No Write Cache if Bad BBU
Current Cache Policy: WriteThrough, ReadAhead, Cached, No Write Cache if Bad BBU
Access Policy: Read/Write
Disk Cache Policy: Enabled

Dem widerspricht allerdings:
Code: 
[root@cluster1 MegaCli]# dmesg | grep sda
SCSI device sda: 975699968 512-byte hdwr sectors (499558 MB)
sda: Write Protect is off
sda: Mode Sense: 1f 00 10 08
SCSI [B]device sda: drive cache: none w/ FUA[/B]
SCSI device sda: 975699968 512-byte hdwr sectors (499558 MB)
sda: Write Protect is off
sda: Mode Sense: 1f 00 10 08
SCSI [B]device sda: drive cache: none w/ FUA[/B]
 sda: sda1 sda2 sda3
sd 0:2:0:0: Attached scsi disk sda
EXT3 FS on sda3, internal journal
EXT3 FS on sda1, internal journal
Adding 2040244k swap on /dev/sda2.  Priority:-1 extents:1 across:2040244k

Oder hab ich da was verwechselt?

Herrjeh wenn man das wenigstens mal ganz praktisch und
schnell einstellen könnte, ich kenn das von den 3Ware und Adaptec-Controllern... aber das LSI-Zeugs ist ja grauenhaft :-/

Das Dateisystem ist lt. /etc/fstab nicht mit sync eingebunden...

Bitte immer her mit weiteren Tipps und Tricks, bin für alles dankbar ;)

Liebe Grüße,

Chris
 
RAID Performance - Test mit bonnie

Hallo zusammen,
ich habe bisher nur Ergebnisse mit Bonnie gesammelt allerdings nur auf ServerLoft L und XL. Ich habe auch Vergleichswerte von Hetzner und 1und1 und bin zur Zeit etwas enttäuscht von der Performance von Serverloft. Das kann aber Festplatten spezifisch sein. Daher bin ich an vergleichen interessiert.

Hätte jemand von Euch Zeit den Bonnie auch einmal auf Euren Kisten laufen zu lassen? Einfach bonnie installieren, und dann einen User angeben und die Filesize für den Test. Das sollte mind. 2 x der Hauptspeicher sein.

Hier für debian/ubuntu besonders einfach:

Code: 
sudo apt-get install bonnie
bonnie -u <mybonnie> -s 8000

Man kann die Ergebnisse nachher einfach in HTML umwandeln lassen, einfach die letzte Zeile des Test-Ergebnis nehmen und umwandeln lassen. Wenn man mehrere Test-Ergebnisse von verschiedenen Rechnern hat, einfach alle letzte Zeilen in eine Datei schreiben, siehe Beispiel:
Code: 
echo <letzte zeile>| bon_csv2html > bonnie.html
cat bonnie.csv | bon_csv2html > bonnie.html

Ich habe bei meinen Tests immer mit 16000 gearbeitet, damit ich L und XL vergleichen kann. Bei XXL müsste man 32000 nehmen. Ach ja, ich habe den WriteCache der Platten ausgeschaltet. Ist mir sonst zu heiß für eine Datenbank-Anwendung!

Hier das Ergebnis für einen ServerLoft L mit 2 x 500 GB SAMSUNG HD502IJ und Filesystem ext3.
Code: 
Version  1.03b      ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
XL.serverloft 16000M 24532  81 28574  13 18201   6 24763  69 45927   5 215.3   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
XL.serverloft.de  16 21702  74 +++++ +++ 11813  25 30152 100 +++++ +++ 31600  63

und hier das Ergebnis für einen ServerLoft L mit 250 GB WD2500AAJS-0 und Filesystem ext3.
Code: 
Version  1.03b      ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
L.serverloft 16000M 24532  81 28574  13 18201   6 24763  69 45927   5 215.3   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
L.serverloft.de  16 21702  74 +++++ +++ 11813  25 30152 100 +++++ +++ 31600  63

Bin gespannt auf Eure Ergebnisse!
Simon
 
CryoGenID said:
Current Cache Policy: WriteThrough, ReadAhead, Cached, No Write Cache if Bad BBU
Click to expand...

Du hast nur den Lese-Cache an. Ich habe auf meinem XL auch den Schreibcache aktiviert (WriteBack statt WriteThrough).

Schreibcache ist nicht ohne Risiko, weil bei einem Stromausfall oder Hard-Reset das Filesystem beschädigt werden kann. Ich gehe davon aus, daß ein Stromausfall beim Provider eher selten vorkommt, und daß vor einem Hard-Reset der Server in der Regel eh schon längere Zeit hing und somit der Controller die letzten Änderungen auf die Platte flushen konnte (das ist ja u.a. der Vorteil bei einem Hardware-RAID).

Die Performance der Serverloft-Hardware ist ohne Schreibcache für meine Zwecke unbrauchbar. Bei 1&1 ist der Schreibcache per Default aktiviert, und in mehreren Jahren habe ich damit bislang erst einen wirklichen Filesystemcrash gehabt -- und dabei wurde der Hard-Reset irrtümlich im laufenden Betrieb ausgelöst.

Natürlich rede ich mir den Schreibcache damit schön, sicherer wäre definitiv ohne.

@Simon: Meinst Du bonnie++?
 
bonnie und bonnie++

Hi Dexter,

ja, ich meine bonnie++. Beim installieren mit debian/ubuntu wird bonnie direkt zu bonnie++ "umgesetzt"!

bin gespannt auf deine Ergebnisse!
simon
 
Dexter,

danke für Deine Antwort!
Sag mal wie setzt du das Ganze denn auf WriteBack?
Ich habs mit dem blöden Windows-Tool versucht, der setzt das aber nicht.
Nach einem Neustart ist die Einstellung aber wieder weg, bzw. ich glaub sogar nach einem Neustart des Windows-Tools.
Der speichert das nicht...

Wär super wenn Du mir da weiterhelfen kannst wie das gesetzt werden muss :-)

Liebe Grüße,

Chris
 
Update:
Es "scheint" jetzt geklappt zu haben...
Also freiwillig leg ich mir kein LSI-Controller zu *gg*
Da weiß man ja nie obs nun geklappt hat oder nicht ^^

So schauts jetzt aus:
Code: 
Throughput 169.566 MB/sec  2 clients  2 procs  max_latency=463.191 ms
Throughput 186.371 MB/sec  4 clients  4 procs  max_latency=1191.357 ms
Throughput 220.085 MB/sec  6 clients  6 procs  max_latency=293.682 ms
Throughput 226.035 MB/sec  8 clients  8 procs  max_latency=1518.258 ms
Throughput 173.099 MB/sec  10 clients  10 procs  max_latency=12658.007 ms

Und hier mit dem -s -S Switch:
Code: 
Throughput 42.6331 MB/sec (sync open) (sync dirs)  2 clients  2 procs  max_latency=23.598 ms
Throughput 59.755 MB/sec (sync open) (sync dirs)  4 clients  4 procs  max_latency=78.134 ms
Throughput 48.7086 MB/sec (sync open) (sync dirs)  6 clients  6 procs  max_latency=756.202 ms
Throughput 47.1949 MB/sec (sync open) (sync dirs)  8 clients  8 procs  max_latency=6194.713 ms
Throughput 42.1267 MB/sec (sync open) (sync dirs)  10 clients  10 procs  max_latency=6431.808 ms

Komisch ist nur das hier mitten im Test:
Code: 
cluster1 kernel: Disabling IRQ #7

Was kann das denn sein!?

Danke schön und liebe Grüße,

Chris
 
Also bonnie++ stresst die Kiste doch schon etwas mehr bzw. länger als dbench, daher hier erstmal nur die Werte von meinem Serverloft XL (mit Writecache):

Code: 
Version 1.01d       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
ns17         16000M 42864  51 48381  19 23933   8 47546  66 53100   6 159.6   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++

Sieht seltsam aus, daher nochmal mit "-f -b" (nur blockweise und ungepuffert):

Code: 
Version 1.01d       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
ns17         16000M           49322  20 24687   8           51160   6 112.9   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16   405   2 +++++ +++   356   1   355   2 +++++ +++   455   2

Also nur marginale Unterschiede, und eine angebliche Performance von rund 50 MB/sec lesend wie schreibend und egal ob synchron oder gepuffert...? Ich glaube da sind die Ergebnisse von dbench (synchron) näher an der Realität, oder?

@Chris: IRQ 7 könnte der Controller sein, auf dem XL ist IRQ 7 nicht belegt. Schau mal in /proc/interrupts.
 
dexter said:
eine angebliche Performance von rund 50 MB/sec lesend wie schreibend
Click to expand...
Wenn man davon ausgeht, dass einzelne Platten erwarteterweise so um die 60-90MB/Sek. durchsetzen können und da noch ein RAID-Controller dazwischen hängt, würde ich 50MB/Sek. als durchaus plausiblen Wert ansehen.
 
Bonnie und Soft-Raid

Hallo Dexter,

ich schließe mich meinem Vorredner an. Ich halte die Test-Ergebnisse auch für valide. Insbesondere halte ich bonnie für sehr gut, weil beim wiederholten testen immer sehr ähnliche Ergebnisse herauskommen, ein wichtiger Punkt beim Testen.

Wir haben einen anderen Server als SoftRaid-I bei 1und1 und der fühlt sich sehr schnell an, bei manuellen TestCases (Backup von 27GB Datenbank,...) und die Ergebnisse von Bonnie sind hier auch wesentlich besser, siehe hier:
Code: 
Festplatte: 2 x ST3500820AS, 500 GB (Barracuda 7200.11), 32MB Cache
Version  1.03      ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
softraid@1und 8000M 71063  91 87939  27 37011  16 66315  94 90672  21 389.2   2
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
softraid@1und1   16  6226  36 +++++ +++  5053  17  5602  26 +++++ +++  4240  19

Jetzt frage ich mich, ob es nicht besser wäre, die ServerLofties in den JBOD Mode zu betreiben und einen Test mit einem Software-Raid zu machen. Hat das jemand von Euch getestet? Die andere Erklärung wäre, dass die Platten der ServerLofties einfach nicht schnell genug sind? Gibt es hierzu Meinungen/Erfahrungen? Oder mehr Test-Cases für Bonnie auf verschiedenen Servern?

BG!
Simon
 
So, inzwischen hab ich nachts mal bonnie++ und dbench auf meinen grossen 1&1-Kisten laufen lassen. Leider sind die rund um die Uhr beschäftigt, d.h. auch während des Tests liefen noch Batchjobs, die die Ergebnisse etwas verfälschen.

bonnie hat leider nur auf dem 3XL funktioniert, hier die Ergebnisse:

Code: 
Version 1.01d       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
ns16         16000M 19557  12 18525   1 14558   1 35464  28 39449   1 119.9   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16   471   1 +++++ +++   545   1   529   2 +++++ +++   380   1

Diese Ergebnisse passen überhaupt nicht, weder zu meinen anderen Tests noch zur gefühlten Performance. Der 3XL hatte um die Testzeit auch nicht genug Load um so einen Unterschied zum Serverloft zu begründen.

dbench zeichnet ein komplett anderes Bild:

Code: 
Throughput 37.9105 MB/sec (sync open) (sync dirs)  1 clients  1 procs  max_latency=94.872 ms
Throughput 45.3201 MB/sec (sync open) (sync dirs)  4 clients  4 procs  max_latency=3783.868 ms
Throughput 48.0626 MB/sec (sync open) (sync dirs)  8 clients  8 procs  max_latency=2460.667 ms
Throughput 52.009 MB/sec (sync open) (sync dirs)  12 clients  12 procs  max_latency=3030.352 ms
Throughput 43.346 MB/sec (sync open) (sync dirs)  16 clients  16 procs  max_latency=2945.115 ms
Throughput 38.1904 MB/sec (sync open) (sync dirs)  20 clients  20 procs  max_latency=2481.108 ms

Das entspricht sehr viel eher dem gefühlten Performanceunterschied zum Serverloft, also daß der 3XL bei Plattenoperationen etwa doppelt so schnell ist.

dbench bringt auch mein Problem mit der (Schreib-)Performance meines 4XL sehr klar auf den Punkt:

Code: 
Throughput 25.4621 MB/sec (sync open) (sync dirs)  1 clients  1 procs  max_latency=7806.794 ms
Throughput 26.7889 MB/sec (sync open) (sync dirs)  4 clients  4 procs  max_latency=5954.422 ms
Throughput 16.7237 MB/sec (sync open) (sync dirs)  8 clients  8 procs  max_latency=9694.435 ms
Throughput 7.11691 MB/sec (sync open) (sync dirs)  12 clients  12 procs  max_latency=12735.252 ms
Throughput 3.72707 MB/sec (sync open) (sync dirs)  16 clients  16 procs  max_latency=8489.875 ms
Throughput 4.6245 MB/sec (sync open) (sync dirs)  20 clients  20 procs  max_latency=12190.388 ms
Entspricht leider der Realität, die normale Leseperformance ist schon schlechter als beim 3XL und wenn genügend viel geschrieben werden muss kommt die Kiste zum Stillstand. Für größere Datenbankanwendungen dadurch leider völlig ungeeignet.

Falls hier noch jemand ist, der einen 4XL hat, würde ich mich sehr über einen Erfahrungsaustausch freuen.
 
Hier noch das bonnie-Ergebnis für den 1&1 4XL (HW RAID 5):

Code: 
Version 1.01d       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
ns15            32G 14504   9 14998   1  9929   1 47873  42 65636   5 181.0   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16   212   0 +++++ +++   716   2   330   1 +++++ +++   713   2

(bei einem sonstigen Load von ca. 0,6 - 0,8)
 
You must log in or register to reply here.
Back
Top