Menü Schließen

Linux Raid Resync und Rebuild beschleunigen

Unix Shell

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

4 Kommentare

    • JARVIS

      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…

    • Maik

      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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert