Debian Squeeze und 3ware - Performance

S

Serow

0
Hi,

ich habe einen 3ware Controller mit 4 SATA anschlüssen. Daran befinden sich 4 1.5TB Festplatten (7200rpm) im RAID5. Mir ist natürlich klar, dass das was man "write penalty" nennt einen negativen Einfluss auf die Schreib-Performance hat, aber das hier ist wohl übertrieben schlecht oder?

Code: 
root@ironman:~# dd if=/dev/zero of=/dev/vg1/storage-3 bs=10M count=100
100+0 records in
100+0 records out
1048576000 bytes (1.0 GB) copied, 65.223 s, 16.1 MB/s
root@ironman:~#

Gelesen krieg ich dagegen deutlich mehr:

Code: 
root@ironman:~# dd if=/dev/vg1/storage-3 of=/dev/null bs=10M count=1000
1000+0 records in
1000+0 records out
10485760000 bytes (10 GB) copied, 55.7013 s, 188 MB/s
root@ironman:~#

Sind die 16,1MB/s nicht viel zu wenig? Woran kann das liegen?

Grüße
serow
 
mh ... gute frage ...

ich meine mich erinnern zu können mal was über platten gelesen zu haben, die intern mit 4k blocks arbeiten ... wenn du sowas im raid hast, und der controller 512b blocks abgleichen will, resultiert jeder SINGLE disk write im lesen des zugehörigen 4k blocks, dem modifizieren des jeweiligen 512b abschnitts im block, und dem schreiben des 4k blocks ... sowas könnte auch diesen bottleneck verursachen ... hast du die möglichkeit die blockgröße des raids zu bestimmen? falls ja, versuch die mal die üblichen verdächtigen 2er potenzen

auch interessant zu wissen: wie siehts aus wenn du eine platte aus dem array nimmst? also RAID5 mit 2+1 fährst ... gleiches problem?
 
Hi,

also die Stripe Size ist 256k.

Code: 
root@ironman:~# tw_cli /c0 show

Unit  UnitType  Status         %RCmpl  %V/I/M  Stripe  Size(GB)  Cache  AVrfy
------------------------------------------------------------------------------
u0    RAID-5    OK             -       -       256K    4190.92   RiW    ON     

VPort Status         Unit Size      Type  Phy Encl-Slot    Model
------------------------------------------------------------------------------
p0    OK             u0   1.36 TB   SATA  0   -            ST31500341AS        
p1    OK             u0   1.36 TB   SATA  1   -            ST31500341AS        
p2    OK             u0   1.36 TB   SATA  2   -            ST31500341AS        
p3    OK             u0   1.36 TB   SATA  3   -            ST31500341AS        

Name  OnlineState  BBUReady  Status    Volt     Temp     Hours  LastCapTest
---------------------------------------------------------------------------
bbu   On           Yes       OK        OK       High     0      xx-xxx-xxxx  

root@ironman:~#

Leider kann ich an dem RAID jetzt nicht beliebig rumfingern, weil da schon Nutzdaten drauf sind. Ich habe kürzlich auf Debian Squeeze geupdatet. Kann mich nicht erinnern mit Lenny ähnlich schlechte Performance gehabt zu haben. Ich werde heute nochmal downgraden und das testen. Melde mich dann.

Grüße
serow
 
Hi,

es ist eine eigene PCI Karte von 3ware (näheres sie unten), von daher nehme ich an es ist eine "dedizierte XOR Einheit".

Code: 
root@ironman:~# tw_cli show

Ctl   Model        (V)Ports  Drives   Units   NotOpt  RRate   VRate  BBU
------------------------------------------------------------------------
c0    9650SE-4LPML 4         4        1       0       1       1      Fault    

root@ironman:~#

ciao
serow
 
Hi,

ich hatte ja erst Debian Squeeze in Verdacht, aber nachdem ich SystemRescueCD und Ubuntu Live gebootet habe und ebenfalls dieselbe schlechte Performance messe ist Debian nun nichtmehr unter Verdacht ;)

Daraufhin habe ich mir die Controller Settings angeschaut: Write Cache = Disabled - das klingt doch schonmal verdächtig oder? Also hab ich den Parameter geändert. Als ich aus dem Setup raus wollte und die Änderungen speichern wollte sagte er mir nur: "Parameter not changeable." Was haltet ihr davon? Darf / Soll das so sein?

Code: 
root@ironman:~# tw_cli /c0/u0 show cache
/c0/u0 Write Cache = off

root@ironman:~# tw_cli /c0/u0 set cache=on
Setting Write Cache Policy on /c0/u0 to [on] ... Failed.
Parameter not changeable 


root@ironman:~#

Nachtrag: Kann es sein, dass man ohne / mit kaputten BBU den Write Cache nicht einschalten kann?

ciao
serow
 
Zuletzt bearbeitet:
er mag solche dinge evtl nicht wenn auf das gerät zugegriffen wird ... war das raid zu dem zeitpunkt gemounted?

hat der controller evtl ein eigenes bios in dem man solche dinge beim booten einstellen kann?

nachtrag: ... die bbu soll normalerweise dafür sorgen, dass falls beim schreiben der strom ausfällt, die dinge im cache noch geschrieben werden... wenn die weg ist, wäre es durchaus nachvollziehbar, dass aus sicherheitsgründen der schreib cache abgeschaltet wird ... das sollte im handbuch stehen ...
 
Zuletzt bearbeitet:
also wenn ich meinem controller die bbu wegnehm, deaktiviert der afaik auch den writecache und das ist bei raid5 tödlich beim schreiben. ich nehme an das bedingt dann auch tatsache die schlechte performance.

ansonst wie ist der erkenntnis stand jetzt? das kommt nicht so richtig aus deinem post raus! (im übrigen würd ich nen raid5 mit writecache aktiv und ohne bbu nicht betreiben wollen! ;))
 
Hi easteregg,

genauso wie du es wiederholt hast ist es auch. Das BBU ist im A**** und deswegen der Write Cache auch weg. BBU ist schon bestellt ;)

Grüße
serow
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben