System ist ein Debian Whezzy. Ich habe des öfteren mit Raid5 oder Raid6 Systemen zu tun. Dabei füge ich, oder entferne fehlerhafte Festplatten, alles als Fakeraid / Softwareraid unter Debian und mittels mdadm. Leider ist der rebuild oder auch das resync meistens sehr lange, teilweise bis zu 24h. Da mich das störte suchte ich im Netz nach Möglichkeiten, die das beschleunigen. Nachfolgend ein paar Möglichkeiten, die jeder auf eigene Gefahr an seinem System durchführen kann.
Ausgangslage
MD0, MD1, MD2
md2 : active raid6 sda4[0] sdd4[3] sdc4[2] sdb4[1]
5836637184 blocks super 1.2 level 6, 512k chunk, algorithm 2 [4/4] [UUUU]
[>………………..] resync = 3.7% (108335548/2918318592) finish=1388.7min speed=33724K/sec
Tipp 1 – die /proc/sys/dev/raid/{speed_limit_max, speed_limit_min} Kernel Optionen
Bereits während des Resync und Rebuilds können Daten auf ein Raid kopiert werden, allerdings mit verringerter Geschwindigkeit für den Sync oder Rebuild, da dies in Abhängigkeit von den aktuellen Lese- und Schreibvorgängen statt findet. Wer jedoch ein System hat, dass entweder genug Reserven besitzt oder schnell fertig werden soll der kann die Lese- und Schreibgeschwindigkeit über zwei Dateien steuern.
Die Standardwerte bzw. den aktuellen Status anzeigen:
# sysctl dev.raid.speed_limit_min
dev.raid.speed_limit_min = 1000
# sysctl dev.raid.speed_limit_max
dev.raid.speed_limit_max = 200000
Achtung nachfolgende Änderungen der Werte führen zu einem Anstieg der CPU-Last und dem Mehrverbrauch von Arbeitsspeicher.
Wenn Resync- oder Rebuild unter die angegebene Geschwindigkeit von 50.00kiB (ca. 50MB) fallen, wird die Lese- und Schreibgeschwindigkeit verlangsamt
# echo 50000 > /proc/sys/dev/raid/speed_limit_min
Die maximale Geschwindigkeit für den Resync- oder Rebuild wird maximal 200.000kiB (ca. 200MB) betragen, der Rest steht dem Lese- und Schreibzugriff zur Verfügung.
# echo 200000 > /proc/sys/dev/raid/speed_limit_max
Wenn man die Defaultwerte überschreiben möchte, sodass diese beim nächsten Sync oder Rebuild verwendet werden, dann geht dies über die /etc/sysctl.conf
################NOTE ################
## You are limited by CPU and memory too #
###########################################
dev.raid.speed_limit_min = 50000
## good for 4-5 disks based array ##
dev.raid.speed_limit_max = 2000000
## good for large 6-12 disks based array ###
dev.raid.speed_limit_max = 5000000
Tipp 2 – ändern der read-ahead Option
Setzen der read-ahead Option in 512byte Sektoren pro Raid Device:
echo „Setting read-ahead to 32 MiB for /dev/md1“
blockdev –setra 65536 /dev/sda
blockdev –setra 65536 /dev/sdb
blockdev –setra 65536 /dev/sdc
blockdev –setra 65536 /dev/sde
…..64MB sind 131072
blockdev –setra 65536 /dev/md2
Überprüfen
blockdev –report
RO RA SSZ BSZ StartSec Size Device
rw 65536 512 4096 0 3000592982016 /dev/sdb
rw 65536 512 4096 2048 98566144 /dev/sdb1
rw 65536 512 4096 194560 10000269312 /dev/sdb2
rw 65536 512 4096 19726336 1999634432 /dev/sdb3
rw 65536 512 4096 23631872 2988492980224 /dev/sdb4
rw 65536 512 4096 0 3000592982016 /dev/sda
rw 65536 512 4096 2048 98566144 /dev/sda1
rw 65536 512 4096 194560 10000269312 /dev/sda2
rw 65536 512 4096 19726336 1999634432 /dev/sda3
rw 65536 512 4096 23631872 2988492980224 /dev/sda4
rw 65536 512 4096 0 3000592982016 /dev/sdc
rw 65536 512 4096 2048 98566144 /dev/sdc1
rw 65536 512 4096 194560 10000269312 /dev/sdc2
rw 65536 512 4096 19726336 1999634432 /dev/sdc3
rw 65536 512 4096 23631872 2988492980224 /dev/sdc4
rw 65536 512 4096 0 3000592982016 /dev/sdd
rw 65536 512 4096 2048 98566144 /dev/sdd1
rw 65536 512 4096 194560 10000269312 /dev/sdd2
rw 65536 512 4096 19726336 1999634432 /dev/sdd3
rw 65536 512 4096 23631872 2988492980224 /dev/sdd4
rw 256 512 4096 0 9991749632 /dev/md0
rw 4096 512 4096 0 3996123136 /dev/md1
rw 65536 512 4096 0 5976716476416 /dev/md2
Tipp 3 – ändern der stripe-cache-size Option
Diese Option bestimmt die Seiten pro Device, welche die gleichzeitige Synchronisation von Lesen und Schreiben durchführen. Der Standardwert ist 256, gültige Werte sind von 17 bis 32789. Diesen Wert zu erhöhen, kann die Performance bei einem Sync in einigen Situationen verbessern. Allerdings kostet es auch etwas Arbeitsspeicher, sodass ein zu hoher Wert dem System keinen Speicher mehr übrig lässt und zum einfrieren veranlasst. Eine Faustformel ist:
Speicher_Verbrauch = System-Page-Size * Anzahl-Festplatten * Stripe-Cache-Size
Diese Option ist „sicher“, d.h. sie führt zu keinem Datenverlust. Einige Admins haben sie sogar im Bootscript untergebracht, da sie immer nur zur Systemlaufzeit gültig ist.
# Set stripe-cache_size for RAID5.
echo „Setting stripe_cache_size to 32 MiB for /dev/md1“
echo 32768 > /sys/block/md2/md/stripe_cache_size
Kontrolle
# cat /sys/block/md2/md/stripe_cache_size
32768
Diese Änderung brachte bei mir die größte Änderung im Rebuild, während die Schritte zuvor nichts bewirkten:
md2 : active raid6 sda4[0] sdd4[3] sdc4[2] sdb4[1]
5836637184 blocks super 1.2 level 6, 512k chunk, algorithm 2 [4/4] [UUUU]
[=>……………….] resync = 5.1% (151427584/2918318592) finish=443.5min speed=103967K/sec
Allerdings zeigte atop bei allen 4 Disks (Seagate ST3000DM001, eine Auslastung von 100-110%.
Tipp 4 – deaktivieren der NCQ Option auf allen Festplatten
Mit dieser Option ist in vielen Fällen eine erhebliche Steigerung des Sync bzw. Rebuild möglich.
Vorher:
# cat /sys/block/sda/device/queue_depth
31
echo „Disabling NCQ on all disks…“
for i in sd[abcde]2
do
echo „Disabling NCQ on $i“
echo 1 > /sys/block/$i/device/queue_depth
done
Oder einzeln:
echo 1 > /sys/block/sda/device/queue_depth
echo 1 > /sys/block/sdb/device/queue_depth
echo 1 > /sys/block/sdc/device/queue_depth
echo 1 > /sys/block/sdd/device/queue_depth
Tipp 5 – die Bitmap Option zum vergrößern des Raids oder Resync
Angepasster Befehl zum vergrößern des Raid:
# mdadm –grow –bitmap=internal /dev/md2
Nachdem das Raid vergrößert oder vollständig gesynct ist muss die Option wieder deaktiviert werden:
# mdadm –grow –bitmap=none /dev/md0
Kontrolle der Änderung und Anzeige des aktuellen Status
# cat /proc/mdstat
# mdadm -D /dev/md2 oder mdadm –detail /dev/md2
# watch iostat -k 1 2
Quelle: http://www.cyberciti.biz/tips/linux-raid-increase-resync-rebuild-speed.html
Interessiert in verschiedenste IT Themen, schreibe ich in diesem Blog über Software, Hardware, Smart Home, Games und vieles mehr. Ich berichte z.B. über die Installation und Konfiguration von Software als auch von Problemen mit dieser. News sind ebenso spannend, sodass ich auch über Updates, Releases und Neuigkeiten aus der IT berichte. Letztendlich nutze ich Taste-of-IT als eigene Dokumentation und Anlaufstelle bei wiederkehrenden Themen. Ich hoffe ich kann dich ebenso informieren und bei Problemen eine schnelle Lösung anbieten. Wer meinen Aufwand unterstützen möchte, kann gerne eine Tasse oder Pod Kaffe per PayPal spenden – vielen Dank.
Hi,
toll dass Du den Artikel auf Deutsch übersetzt hast. Die Quellangabe würde ich aber noch gut finden. Das Original:
https://www.cyberciti.biz/tips/linux-raid-increase-resync-rebuild-speed.html
Gruss
Martin
Hi Martin,
danke für deinen Kommentar, aber lies den Artikel bitte bis zum Ende, denn dort steht die Quelle und das ist genau der Link den du hier angegeben hast. Ich schreibe aber gleich nochmal ein Quelle: dazu 🙂
edit: erledigt…
Ich dachte NCQ würde den Durchsatz erhöhen.
Warum schlägst du vor das zu deaktivieren?
Oder anders gefragt: Woher kommt der Performancezuwachs?
Hallo,
ja das verwunderte mich auch. Im Groben – Native Command Queuing aktiviert bedeutet ja, dass viele Anfragen zur Abarbeitung zwischengespeichert (Queue) werden. Daraus sollen dann gleichzeitige Abfragen schneller zur Verfügung stehen, was zu einer Performancesteigerung führt. Dies kann jedoch die Art und Weise wie der Linux Kernel die Disks bei einem Raid rebuild abarbeitet, stören. Im Ergebnis gibt es mit NCQ aktiv, keinen Boost, oder gar eine Verzögerung bei der Abarbeitung der Queue, was das Rebuild stark verzögert. Am besten selber ausprobieren.