PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Software Raid 5 Performance ist erbärmlich



parityman
06.04.09, 12:14
Hallo,

Es geht um einen bzw. zwei Server mit einem Software-Raid.
Vorweg: Die Server wurden nicht von mir installiert ich muss es nur "ausbaden" ;-)
Zur Hardware: Jeder Server ist ein INTEL SR2500 mit einem Xeon 5110 (DC 1.60GHz), 2 GB Ram (Mainboard ist von INTEL mit einem 5000P Chipsatz). Verbaut ist 1x80GB Festplatte (System) und 5x750GB Seagates - alles am onbaord SATA-Controller.

Vom Vorgänger wurde ein Software Raid5 über die 5 Seagate Platten erstellt und darüber ein lvm konfiguriert. eigentlich scheint alles soweit auch Problemlos zu funktionieren. Es gibt keine Fehlermeldung im mdadm, keine Fehlermeldungen im syslog.

Das Problem: Wenn man Daten übers Netzwerk kopiert (mit scp z.b.) und aufs LVM schreibt, dann schreibt er mit einer Geschwindigkeit von ca 500KB in der Sekunde(!!!).
Wenn man Daten von der Systemplatte auf das LVM schreibt ist genau das selbe Problem festzustellen! Kopiert man jedoch per scp Daten auf die Systemplatte (also nur als Test) erhält man gute 50MB/s was völlig Okay ist. Ein direktes Hardwareproblem kann ich fast ausschließen, da ich einen Baugleichen Server habe, der auch identisch installiert ist, der genau die selben Probleme macht. Die CPU Last ist im übrigen praktisch immer bei 0%. Das Dateisystem ist xfs und die Chunk-Size 64k. Die LesePerformance ist natürlich auch bescheiden und liegt bei so ca 8MB/s.

ein hdparm -tT aufs lvm bringt ca 100MB/s ein hdparm -tT aufs md Raid ca 215MB/s lesend


Was ist hier das Problem? es gibt keinen Prozess der auf die Platten zugreift. ist LVM in Kombination mit einem raid5 "inkompatibel"?

Danke!

marce
06.04.09, 12:22
ich denke mal, bei dem System wird einiges zusammenkommen Software Raid, 5 Platten am gleichen Controller / Bus, ... - wobei 500k/s selbst dafür schon erbärmlich sind...

Welches OS in welcher Version läuft dann auf dem Ding? Poste bitte auch mal mehr Details über die Raid-Konfiguration und wie das LVM genau eingebettet ist...

parityman
06.04.09, 12:44
Das ist ein Debian etch mit backports-Paketen

Was willst du denn genau wissen zur config von mdadm?
Hier mal der Auszug von mdstat:

md0 : active raid5 sdb1[0] sdf1[4](S) sde1[3] sdd1[2] sdc1[1]
2197715712 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]


und hier ein lvdisplay:

storage1:/etc/lvm# lvdisplay
--- Logical volume ---
LV Name /dev/store/master
VG Name store
LV UUID t9Rjce-hChf-5eGx-nVS2-2MP2-Q0j7-DLAhxx
LV Write Access read/write
LV Status available
# open 1
LV Size 900,00 GB
Current LE 230400
Segments 1
Allocation inherit
Read ahead sectors 0
Block device 253:0



Habe noch nie LVM gebraucht, kenn mich also leider nicht genau aus was der wo speichert. Wenn du irgendein Konfigfile brauchst, musst es nur sagen!

Naja, selber Controller ist schon Richtig, nur reden wir hier ja nicht von einem billig Enduser Board, sondern von echter Server Hardware. Ich hab das selbe Server Modell hier auch mit je 3 Raid1 (6 gleiche platten) bei dem Jedes Raid1 das Maximum der Festplatten erreicht (Velociraptor Platten von WD ~ 126MB/s schreiben ), also gleichzeitig!

marce
06.04.09, 12:48
nur ist leider Raid 1 und Raid 5 mal so überhaupt nicht zu vergleichen, was IO angeht. Und erst recht nicht, wenn es sich um ein SW-Raid 5 handelt. Da ist es auch herzlich egal, ob da ein Desktop-PC oder ein "richtiger" Server da steht - wobei ein "richtiger" Server bitte ein HW-Raid haben sollte :-)

parityman
06.04.09, 12:54
da kostet aber halt der Controller mal eben genausoviel wie der ganze server inkl aller Festplatten :-)
das ist aber ein anderes Thema

AUßerdem denke ich schon dass man die last von 3 Raid1 mit einem Raid5 vergleichen kann - klar ist es eine andere last aber es werden eine Menge Daten über den Controller geschoben - bei beiden Varianten.

marce
06.04.09, 13:02
AUßerdem denke ich schon dass man die last von 3 Raid1 mit einem Raid5 vergleichen kann
nein, kann man leider nicht.

Grob für 1 Block schreiben:
Raid 5: 2 Blöcke lesen, 1x Rechnen, 2 unterschiedliche Blöcke schreiben
Raid 1: 2 id. Blöcke schreiben

2id. Blöcke schreiben lässt sich, je nach Treiber, optimieren...

wird aber leicht OT inzwischen.


LVM bin ich leider nicht so der Held drin (nutzen wir nicht) - wie wurde dieses denn erstellt? Eine einzige vg auf dem md-Device?

parityman
06.04.09, 13:19
ich meinte damit dass das raid5 nicht der alleinige grund sein kann warum da nur 500kb/s geschrieben werden können! dass es definitiv mehr aufwand fürs system is auf ein raid5 zu schreiben is klar...

ja das ist nur ein lv auf dem md raid (ich bin ja am überlegen ob ich den server neu aufsetze, aber ohne lvm)

marce
06.04.09, 13:23
was sind es denn für Daten? Wenige große Dateien oder viele kleine?

Mach doch mal mit dd einen Test und lass 10GB oder so am Stück schreiben...

War das System "schon immer" so lahm und es ist Dir jetzt erst aufgefallen oder hat sich in letzter Zeit an der Performance des Systems was geändert?

bla!zilla
06.04.09, 13:30
Da es sich um SATA handelt, kann man das Problem mit dem gleichen Bus ausschließen. Vom SATA Expander bis zum Controller sind es dann zwar "nur" 3 GB/s (bei SATA II), aber bei den paar Platten sollte das kaum ein Problem darstellen.

RAID 5 hat eine echt miese Schreibperformance, vor allem bei kleinen Dateien. Das hat Marce ja schon gut erläutert. Ich tippe hier eher auf ein Treiberproblem, als auf ein Problem mit der Config. Evtl. mal eine Knoppix reinwerfen. Das RAID und das LVM sollten direkt erkannt werden.

parityman
06.04.09, 13:45
der disk dump bringt genau das selbe Problem. 500kb/s schreiben

Praktisch alle Dateien auf dem lvm haben eine Größe von 2-10MB.

Und ja das System war schon immer so lahm, nur damals hatte ich noch nix mit den Servern zu tun.


Zur Schreibperformance: Egal ob die Datei 1,2 oder 700MB groß ist, es ist immer langsam (bei 1mb gehts halt schneller, da dauert die Übertragung vielleicht 1 Sekunde)

bla!zilla
06.04.09, 14:06
Sicher die Daten und wirf das RAID mal weg. Nicht das daran irgendwas krumm ist. Alternativ mal iostat-Werte liefern. Wenn die IOwait Werte hoch sind, ist das RAID das Problem und bekommt die Daten nicht schnell genug auf die Platte.

parityman
06.04.09, 14:28
storage1:~# iostat
Linux 2.6.24-etchnhalf.1-amd64 (storage1) 06.04.2009

avg-cpu: %user %nice %system %iowait %steal %idle
0,24 0,01 1,34 0,36 0,00 98,06

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 2,33 0,81 40,24 2460588 122222304
sdb 10,25 530,10 67,08 1610179835 203752280
sdc 10,32 530,00 67,53 1609896283 205128064
sdd 10,40 530,15 69,12 1610342322 209967288
sde 10,53 530,21 70,69 1610526365 214713992
sdf 0,00 0,00 0,00 1202 64
md0 33,35 124,11 121,01 376991901 367561564
dm-0 33,13 122,37 121,01 371694045 367561564

bla!zilla
06.04.09, 14:46
Wir brauchen da schon etwas mehr. Und die Daten müssen von dem Zeitpuntk an sein, wo du eine Datei auf das RAID 5 schiebst.

parityman
06.04.09, 15:24
zu diesem zeitpunkt habe ich ein 700mb image per scp draufgeschoben...

wieviel mehr möchtest du haben? soll ich die devices angeben?

so? (während der kopiervorgang läuft; so sehen übrigends alle hdds dieses raids aus (praktisch identische werte))

storage1:/storage/master# iostat -p /dev/sdd
Linux 2.6.24-etchnhalf.1-amd64 (storage1) 06.04.2009

avg-cpu: %user %nice %system %iowait %steal %idle
0,24 0,01 1,34 0,36 0,00 98,06

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sdd 10,40 529,58 69,16 1610436842 210301800
sdd1 75,02 529,58 68,50 1610435730 208302504

Stormbringer
06.04.09, 16:12
Das Problem scheint evtl. nicht einzigartig zu sein ... vllt. erreichst Du ja den Schreiber dieses Beitrags (http://debianforum.de/forum/viewtopic.php?f=27&t=105030), und er kann DIr da einen Tip geben.
Ist der LargeBlockDevice Support im kernel aktiviert (Quelle (http://kerneltrap.org/index.php?q=mailarchive/linux-raid/2008/8/28/expand&sort=asc&order=Date))?

parityman
06.04.09, 17:14
Nein, LBD ist im Kernel nicht aktiviert...ich werd das als erstes versuchen

Danke!

Edit: Ich Seh grad dass in den Kernels vor etchnhalf CONFIG_LBD aktiviert war (also im debian standard binary kernel) - nur da war das Problem ja auch das selbe. Werds natürlich sicherheitshalber morgen früh nochmal Probieren, bin aber sehr sicher dass es mit den anderen Kernels auch nicht besser funktioniert. (die frage ist warum debian in den aktuellen kernel die Option wieder rausgepatcht hat?! schadet ja eigentlich nicht wenns an ist, und Speicherplatz wird ja eh immer mehr)

Das schlimme ist dass man den Server nicht mal eben Backuppen kann und neu aufsetzen. bei 3-5 MB lesen in der Sekunde dauerts schon ein bisschen bis man 800GB woanders hinschaufelt.....

Fly
07.04.09, 06:32
Moin,

wie wäre es wenn du den Raid5 auflöst und auf 2 x Raid1 inkl. Spare. Anschließend kannst du dann beide Raids auf einem LVM betreiben, sollte etwas Performanter sein...

marce
07.04.09, 07:14
Das Raid sollte auch von einer beliebigen Distribution erkannt werden - von dem her kannst Du ja mal versuchen (wie bereits erwähnt) von Knoppix aus auf das System zuzugreifen. Dann zeigt sich vielleicht auch, ob es einfach nur ein Treiberproblem ist - wobei dann Knoppix evtl. der falsche Weg ist, da ebenfalls auf Debian basierend - LiveCDs gibt's ja aber viele.

Evtl. hast Du einfach auch ein Controllerproblem - wir hatten hier mal so einen Fall, wo das schreiben auf HD auch extremst langsam war, nach einem BIOS-Update war dann alles toll (Formatieren einer 500GB-Sata-Platte in 1-2 Minuten statt 45 :-)

"Low-Budget" und Server - da fällt mir als Distri immer CentOS ein, ich will dich nicht von Debian wegbringen (nicht falsch verstehen) - aber sollte die Ursache darin begründet sein wäre das ein guter Ersatz für das jetzige OS...

Ob sich eine Lösung durch Umformatieren und andere Raidlevels erreichen lässt - möglicherweise, der Speicherverlust bei der Lösung 2x Raid1 + Spare ist aber verglichen mit Raid5 astronomisch...

parityman
07.04.09, 07:42
also ich habs mit den kernels getestet - geht wie vermutet auch trotz lbd nicht besser.

zum Controller: ist einfach so, dass 3xraid1 an einem baugleichen System absolut keine Performance Probleme haben. Deshalb kann ich mir dann nicht erklären warum der Controller bei einem Softwareraid erhebliche Probleme macht. sogar die Systemplatte die am selben Controller hängt läuft ja einwandfrei

Wollts gestern schon mit Ubuntu testen. Leider ist wohl das Laufwerk im Server verreckt. Ich bekomm nichtmal mehr meine CD ausm laufwerk :-)

die 2 raid1 fallen aus, da ich dann netto nur 1,4 TB Speicher hab - die wir in 3-4 Monaten locker erreichen werden.(jetzt sinds wenigestens noch 2100GB)

marce
07.04.09, 07:47
Bist Du dir sicher, daß die System 100% baugleich sind? Also wirklich exakt gleiches Board, Controller, Bios, Platten, Verkabelung, Chipsatz?

parityman
07.04.09, 08:16
ja ich bin absolut sicher!

bis auf festplatten und prozessor komplett identisch!

parityman
28.11.09, 09:48
Das Rätsel ist wohl gelöst.

es lag an der option in der fstab welche das lvm mountent


/dev/mapper/store-master /storage/master xfs noexec,sync 0 2

die SYNC option verursacht diese massiven probleme. Fraglich nur wie wichtig nun die option in einem Storageserver ist?!