Tipp bei Linux-SW-Raid5

Tipp bei Linux-SW-Raid5 (32 Beiträge, 549 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Hi !

Wenn wer Speed-Probleme bei einem SW-RAID5 hat (hatte ich gerade bei einem Resync nach Stromausfall):

Probiert mal (neben dem Setzen von sysctl -w dev.raid.speed_limit_min=... ) auch mal

echo 32768 > /sys/block/_MD_DEV_/md/stripe_cache_size

aus.

Letzteres war mir nicht bekannt - und erhöhte die Resync-Geschwindigkeit von 1700KB/sec auf ca. 40000KB/sec bei einem Raid5 auf 6 Platten... Und ich hoffe, dass die Geschwindigkeit in Betrieb nachher ebenfalls ansteigt

.

Für mich sieht es so aus, als ob die stripe_cache_size bei aktuelleren Kerneln auf einem niedrigeren Default-Wert ist. Bei ~2.6.30 war es auch so recht flott, mit 2.6.38 war es brutal langsam...

Bei Maschinen mit weniger Memory kann man sich den Cache verbrauch leicht ausrechnen (wenn man Sorge hat das man oom läuft):

Any value from about 10 to a few thousand should be perfectly safe,
though very large values may cause the system to run short of memory.

The memory used is approximately
stripe_cache_size * 4K * number-of-drives

Where there is a shell, there is a way!

Tja... Da 32k der Maximalwert ist, also 128MxDrives... Hast Du eine Quelle für das Teil ?

Am Beispiel mit 6 Platten:

32k*4k*6=768M. Zumindest zum Raid-Synchronisieren macht es Sinn, denn Resync-Speed von 2M/sec (unter Last beim Hochnehmen der Datenbanken, ...) sind halt schon öde bei ein paar Tera. Das Beschleunigen auf über 40M/sec fand ich sehr cool - eigentlich dachte ich nicht einmal, dass mein Chipsatz das schafft...

Denn um 45MB/sec zu schaffen (bei 6 Platten) muss er ja 45*5MB/sec lesen und parallel 45MB/sec schreiben... Also in Summe 270MB/sec verarbeiten.

Es gibt jedenfalls auch ein zweites "Kernelfile" dort - das zeigte, wieviel aktuell verwendet wurde. Das war _sehr_ volatil... Man könnte das verwenden, um sich an eine optimale Speed heranzutasten.

Spielt da eigentlich noch das read-ahead von hdparm (-a) rein ? Glaublich nicht, denn auf den Platten selbst liegt ja kein Filesystem...

Als "Schrauben" habe ich also:
- stripe_cache_size (/sys)
- blockdev --setra ... /dev/md?
- sysctl -w dev.raid.speed_limit_(min|max) (beim Resync)
habe ich was vergessen ?

Ach ja, blockdev --setra habe ich mal Testweise auf 2x5xchunksize gesetzt (um 2 aufeinanderfolgende chunks über alle Platten einzulesen). Gibt es da Empfehlungen für das XFS, das (im LVM2) draufliegt ?

27.06.2011, 10:11 Uhr - Editiert von kombipaket, alte Version: hier

Tja... Da 32k der Maximalwert ist, also 128MxDrives... Hast Du eine Quelle
für das Teil ?

Der Herr hier verwendet bis 65k Sizes, siehe auch seine Performancemessungen...
Die Formel hab ich aus einem developer-Forum, den Link hab ich allerdings nimmer bei der Hand.

http://inkhornnet.wordpress.com/2010/06/08/io-performance-and-stripe_cache_size-contd/

Spielt da eigentlich noch das read-ahead von hdparm (-a) rein ? Glaublich
nicht, denn auf den Platten selbst liegt ja kein Filesystem...

Richtig, richtig. Readahead ("File prefetching") ist Filebasierend und greift da nicht ein.

- sysctl -w dev.raid.speed_limit_(min|max) (beim Resync)

Aha ich hab da immer /proc/sys/dev/raid/speed_limit_min verwendet

.

Ich hab auch ähnliche Konstellation, Raid5, LVM2 drauf. Beim Rebuilden verwende ich immer o.a. procfile um die Speed zu ändern, sonst hab ich allerdings nicht viel geschraubt.

lg.

Where there is a shell, there is a way!

27.06.2011, 14:17 Uhr - Editiert von A national Acrobat, alte Version: hier

Der Herr hier verwendet bis 65k Sizes, siehe auch seine Performancemessungen...

Da hast was verwechselt. Er verwendet blocksizes von bis zu 64k - ich sprach aber von der stripe_cache_size - und die hat als Maximalwert 32768 - wie man auch in seinen Graphen sieht.

Trotz allem wirkt das System leider recht nachdenklich bei mir - die nr_requests habe ich auch schon raufgeschraubt...

bonnie++ meint

Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -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
i5              22G   914  40 269726  20 113388  14  1788  33 271104  17 150.2   5
Latency             10403us    2343ms    1676ms   24667us     967ms    1349ms
Version  1.96       ------Sequential Create------ --------Random Create--------
i5                  -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16    22   0 +++++ +++    23   0    22   0 +++++ +++    30   0
Latency              3635ms     194us    3187ms    5251ms      55us    3786ms
1.96,1.96,i5,1,1309183495,22G,,914,40,269726,20,113388,14,1788,33,271104,17,150.2,5,16,,,,,22,0,+++++,+++,23,0,22,0,+++++,+++,30,0,10403us,2343ms,1676ms,24667us,967ms,1349ms,3635ms,194us,3187ms,5251ms,55us,3786ms

Also mal alles andere als berauschend

. Wie krieg ich die Latenzen weg ?
Insbesondere die 22 Creates/sec zipfen mich an... Mein Lappy schafft da so 250-270/sec

EDIT:
Mit dem neuen Kernel sieht es nun so aus:

Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -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
i5           22000M  1186  64 249221  24 99683  13  3009  70 393324  28 255.6  14
Latency             12552us    2926ms    1546ms   19480us     187ms     183ms
Version  1.96       ------Sequential Create------ --------Random Create--------
i5                  -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  2435  16 +++++ +++  3716   7  4434  11 +++++ +++  5500  13
Latency               564ms     200us     501ms     926ms      76us     368ms
1.96,1.96,i5,1,1309303213,22000M,,1186,64,249221,24,99683,13,3009,70,393324,28,255.6,14,16,,,,,2435,16,+++++,+++,3716,7,4434,11,+++++,+++,5500,13,12552us,2926ms,1546ms,19480us,187ms,183ms,564ms,200us,501ms,926ms,76us,368ms

Währenddessen war das Teil auch als Server gefordert, ich bin also nun zufrieden

.

Die "grössten" Umstellungen waren:
- Änderung auf 1000Hz (weiterhin Tickless)
- Low latency Preemptive Kernel (davor war es Server)

Scheinbar unterstützen die beiden ordentlich den RAID-IO...

Verblüffend finde ich nur, dass nun die höchste Schreibperformance besser ist als die Leseperformance... getestet mit

#!/bin/bash

set -o errexit

FILE=bubu.bin

for i in {1..3}; do
	sync
	echo 3 > /proc/sys/vm/drop_caches
	echo "stripe_cache_size: ${cache_size} (${i}/3)"
	# for write
	dd if=/dev/zero of=$FILE bs=3145728 count=5460
	# for read
	dd if=$FILE of=/dev/null bs=3145728 count=5460
done

Erhalte ich nun bei den 3 Durchgängen:
- Fürs schreiben: 294, 298 und 342 MB/sec
- Fürs lesen: 328, 308 und 301 MB/sec

Kernel-Config: http://forum.geizhals.at/files/199592/config-2.6.39.2-grueni-1000Hz-1
Parameter setzen: http://forum.geizhals.at/files/199592/hd_schnell.sh

Die Kernel-Config bietet aber sicher noch was zum optimieren...

29.06.2011, 07:05 Uhr - Editiert von kombipaket, alte Version: hier

Guten Morgen.

Danke fürs updaten deines Posts, ich glaub ich muß mir meine IO Config daheim auch mal anschaun

.

lg.

Where there is a shell, there is a way!

Wie krieg ich die Latenzen weg ?

welche xfs-parameter (mkfs und mount)?

die höchste Schreibperformance besser ist als die Leseperformance... getestet
mit

ohne sync am Ende sagt das nicht viel aus, je größer dein buffer, desto weniger schreibt er dann bis irgendwann nachdem dein Script aus ist...

wikileaks.geizhals.org

Was man beim Lesen von Postings und Leserbriefen in großen Medien bedenken sollte

stoppt die Ratingclowns!

Mit den Latenzen (bzw. mit der Perf. überhaupt) bin ich inzwischen ja zufrieden... Und "sync" war im Script, inklusive invalidieren der Buffer:

sync
echo 3 > /proc/sys/vm/drop_caches

Die Parameter sehen bei den LVs wie folgt aus:

Metadaten =/dev/mapper/sata-usr   isize=256    agcount=15, agsize=243712 blks
          =                       sectsz=4096  attr=2
Daten     =                       bsize=4096   Blöcke=3596288, imaxpct=25
          =                       sunit=64     swidth=320 blks
Benennung =Version 2              bsize=4096   ascii-ci=0
Protokoll =Intern                 bsize=4096   Blöcke=2560, Version=2
          =                       sectsz=4096  sunit=64 blks, lazy-count=1
Echtzeit  =keine                  extsz=4096   Blöcke=0, rtextents=0

Angelegt wurden sie mit:

mkfs.xfs -s size=4096  -b size=4096 -d su=262144 -d sw=5 -l su=262144  _ZIEL_

Derzeit experimentiere ich mit Stromverbrauch:
Mit CONFIG_HZ_1000 und CONFIG_PREEMPT stieg der an.

Reicht es, auf CONFIG_PREEMPT_VOLUNTARY zu wechseln ? Oder müssen die HZ runter ?

30.06.2011, 06:31 Uhr - Editiert von kombipaket, alte Version: hier

Und "sync" war im Script, inklusive invalidieren der Buffer:

aber vor dem Schreiben ... d.h. im letzten Durchlauf schreibst du das mal in den Buffer und terminierst, irgendwann später wird's dann tatsächlich geschrieben.

Derzeit experimentiere ich mit Stromverbrauch:
Mit CONFIG_HZ_1000 und CONFIG_PREEMPT stieg der an.

Reicht es, auf CONFIG_PREEMPT_VOLUNTARY zu wechseln ? Oder müssen die HZ
runter ?

http://www.heise.de/open/artikel/Kernel-Log-Hoeherer-Stromverbrauch-durch-BIOS-Bugs-1268394.html kennst du?

Edit: hast du eigentlich barriers ein oder aus? Die können auch ziemlich bremsen ...

wikileaks.geizhals.org

Was man beim Lesen von Postings und Leserbriefen in großen Medien bedenken sollte

stoppt die Ratingclowns!

30.06.2011, 06:31 Uhr - Editiert von mjy@geizhals.at, alte Version: hier

aber vor dem Schreiben ... d.h. im letzten Durchlauf schreibst du das mal in den Buffer und terminierst, irgendwann später wird's dann tatsächlich geschrieben.

Stimmt, das letzte Lesen ist daher mit Vorsicht zu geniessen - danke für die Korrektur.

http://www.heise.de/open/artikel/Kernel-Log-Hoeherer-Stromverbrauch-durch-BIOS-Bugs-1268394.html kennst du?

Kannte ich nicht, danke!
Derzeit teste ich auf einem Dell_Laptop, weil man den Stromverbrauch so schnell merkt

.

Barriers:
Mein Lappy meint bei den LVs:
Jun 29 23:22:25 lappy kernel: [ 8448.850071] XFS (dm-16): Disabling barriers, underlying device is readonly

Mein Server meint nichts dergleichen, ich nehme also an, dass Barriers dort aktiv sind.

30.06.2011, 06:51 Uhr - Editiert von kombipaket, alte Version: hier

Zum Stromsparen:

Daaanke für den Link. Das erklärt die neuen Meldungen

Jun 27 15:49:35 lappy kernel: [ 0.302338] pci 0000:0c:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force'

Es handelt sich dabei um

 lspci -s 0000:0c:00.0
0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)

Auf meinem Server habe ich dasselbe Problem... Hier ist es

02:00.0 SATA controller: JMicron Technology Corp. JMB362/JMB363 Serial ATA Controller (rev 03)

bei diesem Mainboard:
http://geizhals.at/a495244.html

Die Meldungen unterscheiden sich aber noch leicht:
Am Server erhalte ich noch

[    0.468392] Unable to assume _OSC PCIe control. Disabling ASPM

dazu, am Lappy nicht...

Bei welchem der beiden würdest Du dich trauen, pcie_aspm=force aufzudrehen ?
Gibt es irgendwo eine Liste der HW, die das ohne Abstürze schafft ?

Sodale, ich habe am Lappy nun einen neuen Kernel gebaut und von 1000Hz/Low Latency Laptop auf 300Hz/Desktop umgestellt.

Der Reboot zeigte _sofort_ einen geringeren Energieverbrauch (weil geringere Temperatur, wenn X "idlet", ich also nur FF offenhabe und hier poste.

Mein nächster Versuch wird sein, 1000Hz/Desktop.
Meine Vermutung ist, dass der Energieverbrauch genauso wie bei 300Hz sein sollte - und nur der Low Latency Laptop extra frisst... mal sehen.

30.06.2011, 07:20 Uhr - Editiert von kombipaket, alte Version: hier

Bei welchem der beiden würdest Du dich trauen, pcie_aspm=force aufzudrehen ?

beim lappy ...

Sodale, ich habe am Lappy nun einen neuen Kernel gebaut und von 1000Hz/Low Latency Laptop auf 300Hz/Desktop umgestellt.

low latency / PREEMPT wird sicher das CPU scaling irgendwie beeinflussen ... Kannst ja mal schauen, welche Frequenzen / governors da so verwendet werden.

wikileaks.geizhals.org

Was man beim Lesen von Postings und Leserbriefen in großen Medien bedenken sollte

stoppt die Ratingclowns!

Ondemand hatte ich auch bei Low Latency verwendet...

Nach Umstellen auf "normalen" Desktop-Modus sah es beim Lappy Thema Laufzeit und Temperatur wieder gut aus... Am Server teste ich noch.

EDIT:
Sodale, mit 1000Hz/Desktop erhalte ich sehr gute Interaktivität ohne merkbaren Mehrverbrauch an Energie. Die 1000Hz dürften bei einem Tickless-System also nur die Präzision der Ressourcenzuteilung erhöhen - und bei Energieverbrauch gleich bleiben. Powertop meldet auch nicht mehr Aufwachen - passt also.

Danke für die Infos!

04.07.2011, 16:24 Uhr - Editiert von kombipaket, alte Version: hier

Ist das ein Pimperl-Atom, oder wie kommst du auf derart niedrige Geschwindigkeiten?

Ich hab mich vor einer Weile mit RAID5 auf md-Basis beschaeftigt, eines der Ergebnisse gibt's hier zu lesen: http://johannes.truschnigg.info/blog/2009-10-04#0021-2009-10-04-Mehr-Durchsatz-f%C3%BCr-Linux-md-Software-RAID5

Noch ein paar Einwuerfe zum Thread: (spekulatives) readahead arbeitet auf dem Block Layer - alles andere wuerde bei HDDs ja zu evtl. unnoetigen Kopfbewegungen fuehren, und DAS waere alles andere als gut. Wenn du xfs benutzen willst, benutz unbedingt aktuelle userspace-tools (xfsprogs), damit das fs mit den richtigen Optionen angelegt wird - aktuelle builds davon analysieren md-arrays automagisch und optimieren z. B. die Anzahl der internen Subvolumes selbsttaetig. Und wie immer mit XFS - USV nicht vergessen

Ist das ein Pimperl-Atom

Ne, ein i5-661

, oder wie kommst du auf derart niedrige Geschwindigkeiten?

Mit 2.6.32 hatte ich auch noch gute Geschwindigkeiten

.

In deinem Test finde ich übrigens nichts zum Thema Resync-zeiten...

Ja, weil die mit einem Write Intent Bitmap sowieso vernachlaessigbar sind - so eines kannst Du dir auch nachtraeglich ins Array kippen, entweder in den Superblock oder auf ein Extra-Device (eigentlich Filesystem - z. B. auf einer kleinen SSD). Wie auch immer, ein resync sollte rund so schnell sein wie eine der Platten deines Arrays beschrieben werden kann (bei meinem Array daheim sind das um die 100mb/s).

Hast du vielleicht den Kernel selbst gebaut und laesst RAID5/6 Partiy-Daten parallelisiert berechnen? (Es gab da mal einen EXPERIMENTAL config-knob, der das aktiviert hat - danach war die Rate bei mir auch im tiefsten aller Keller!)

Bitmaphabe ich nicht verwendet...

Wegen der unklaren Latenz-Gschichtln gebe ich mal dem 2.6.39.2 eine Chance... Der kompiliert grad..

Sodale, 2.6.39.2 pfeift wie ein Glöckerl...
Obwohl die Platten voll ausgelastet sind (gmediaserver öffnet mal alle MP3s) - ist das Teil _super_-responsive.

Wenn gmediaserver durch ist, poste ich mal die neuen bonnie++-Werte - und meine Änderungen in der .config... Wahrscheinlich morgen.

28.06.2011, 21:02 Uhr - Editiert von kombipaket, alte Version: hier

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung