bonnie-Werte auf Areca mit 16 Platten

JuhuU!

Ich baue grade einige System für einen Kunden zusammen. Die sind mit ja 2x 248er Opterons ausgestattet und haben einen Areca mit 16 Platten verbaut. Sollte also mit einem Harware Raid0 - nur zum Testen nachher Raid6! - abgehen wie 'Schmitz-Katze' ;-) soweit so gut.....
Also ich bekomme 264MB/s schreibend und 194MB/s lesend raus. :-(
Getestet hab ich das mit ner Frenzy - kein SMP!

Unter Linux habe ich im Raid 6 Schon 340MB/s schreibend und fast 400MB lesend - ohne irgendwelche 'tunning-Massnahmen' ... auch kein SMP!

Da ich in den BSD-Sachen nicht soo vertraut bin... kann mir einer damit mal Helfen?
Gibt es da vielleicht beim Dateisystem oder sonstwo noch optimierungs Möglichkeiten?

Achso da sind 16x 320GB WD Platten drin. also Raid0 drauf mit GPT gelabelt.. wegen der Grösse ;-)

Vielen Dank im Vorraus vom Michel
 
hi

also stellt sich fuer micht die frage welches fs du unter linux genutzt hast.

unter bsd musst du hand anlegen da das filesystem sehr konserativ ist gegenueber
linux was die setting betrifft.

gerade bei bonnie kann man durch tuning einiges ereichen

wichtiges tool dafuer tunefs naeheres in der man page.

holger
 
unter bsd musst du hand anlegen da das filesystem sehr konserativ ist gegenueber
linux was die setting betrifft.

Das liest man haeufiger. Was ich allerdings noch nie gelesen habe sind konkrete Massnahmen, die den Durchsatz mehr als unerheblich erhoehen. Gerade bei tunefs(8) ist doch mit Softupdates die einzige wirklich beschleunigende Option bereits der Default. Wenn ich async und noatime mal als nicht gebraeuchliche Spezialfaelle abtue - was kann man denn da noch machen?
 
moin
@fader die tuning massnahmen haengen vom anwendungszweck ab.

wenn du z.b. nen email server betreibtst mit courier-imap wo jede mail
einzeln gespeichert wird mit im schnitt 2k groesse das kannst du
durch das hochsetzen von

tunefs: average number of files in a directory: (-s) 64

auf z.b. 10000 nen zimlichen boost erleben was den zugriff auf die dateien betrifft.

tunefs: maximum blocks per file in a cylinder group: (-e) 2048
tunefs: average file size: (-f) 16384
tunefs: average number of files in a directory: (-s) 64

all diese parameter haben massiv einfluss auf das caching und zugriffst verhalten
von freebsd.

zurueck zu bonnie

mach deinen test naoch mal und merkt die ergebnisse.
danach setzt du den wert

tunefs: average file size: (-f) 16384

auf z.b. 65535

und mach deinen test nochmal ......... dann wirst du sehen das die werte von bonnie
besser werden wuerde auber auch bedeuteten das der besagte mailserver langsamer wird.

holger
 
Moin Moin!

Erstmal Danke für die Antworten!
Unter linux verwende ich bei den Array-Grössen XFS oder JFS. Alles andere ist zu langsam ;-)
Ich hatte mir schon gedacht das es Möglichkeiten zum Caching-Verhalten gibt wie blockdev unter linux.
Aber ich habe jetzt viele Einstellungen probiert und lange gestestet. Aber die Werte weichen nur geringfügig von den Anfangswerten ab.
Ich denke es ist der Areca Treiber der hier die performance bremst. Unter linux ist der lange Zeit auch nicht wirklich brauchbar gewesen.

Gruss vom Michel
 
Nachtrag :-)

also ich habe nochmals rumgespielt....

...wenn man die slices direkt mit newfs und optionen (-U -b -f) anlegt und den faktor 8:1 zwischen block & fragmentsize beachtet (steht in man newfs) bekommt man(n) ein anderes ergebnis...

270M/s schreibend
340MB/s lesend

...gleich teste ich noch den klamauk im smp-betrieb und dann schaunmer mal! :rolleyes:

danke nochmals für die Tips - alleine hätte ich warscheinlich heut noch gesucht :zitter:

gruss vom michel
 
Immer noch langsamer als dein Linux Ergebnis, wie es scheint. Aber immerhin... vielleicht liegt es ja wirklich am Treiber.
 
Zurück
Oben