SHR Rebuild Fortschritt - DS410j

[ChRo]

Die SHR Rebuild Geschwindigkeit auf meiner DS410j (Backupserver der DS414) ist komplett eingebrochen. Von 7MB/s und 90% Prozessorlast auf 175kB/s und 8% Prozessorlast. Der Einbruch dauert nunmehr schon 1,5 Tage an, eine Ansammlung von kleineren Dateien müsste längst durch sein.

Top zeigt 100MB Speicherbelegung und 20MB frei an. Ursprünglich waren etwa 10% Fortschritt pro Tag zu verzeichnen, das war zwar nicht üppig, aber angesichts des Alters der DS410j erträglich. Die numehr auf 266 Tage Restzeit taxierte Dauer ist aber zuviel. Stripe_cache und NCQ wurden bereits optimiert und haben die Rebuild speed bereits von 3,5 auf 7MB/s verbessert.

Aktuell sind 3x 8TB Seagate Archive im Einsatz, welche eine Expansion von HD 1 auf 2+3 durchführen.

Für Hinweise, was die DS so ausbremst oder wie ich die Ursache feststellen könnte, wäre ich sehr dankbar.

 

[dil88]

Dir ist schon bekannt, dass die Archive-Platten durch die verwendete SMR-Technik bei umfangreichen Schreiboperationen wie einem RAID-Rebuid in ihrer Performance einbrechen? Ob das die Ursache für die schon geringen 7 MB/s oder die noch geringere Rate ist, kann ich nicht sagen, aber es dürfte einen Einfluss haben.

 

[ChRo]

Begleitumstände

Die Entscheidung fiel aufgrund vieler weiterer Umstände:

Einerseits weil es eben der Backup Server war, andererseits, weil die DS410j mit dem kleinen Prozessor auch nicht unbedingt übermotorisiert ist. Da die DS410j am anderen Ende des Hauses steht, der nur mit 100Mbit angebunden ist, schleicht ein Backup dorthin sowieso nachts mit ca 8 MB/s übers Netz. Insofern waren mir die im Internet kursierenden 5MB/s in der Festplattenmitte schnell genug.

Wenn jedoch die Schreibrate dauerhaft auf unter 200kb/s einbricht, deklassiert dies die Seagate Archive als Backup HD komplett. Deshalb meine Frage, ob irgendwelche Tipps existieren, wie ich den Sachverhalt näher prüfen kann ?

Hinweis: Die anfänglichen 7MB/s gingen mit einer Prozessorauslastung von 90% einher. Das fand ich in Anbetracht der betagten Hardware als angemessen, ich erwarte von dem kleinen Prozessor keine Wunder.

 

[dil88]

Als Backupplatte ist die Archive ja auch nicht verkehrt, aber für ein RAID-5/SHR-1 ist sie meiner Meinung nach keine gute Wahl. Aber wie gesagt: Vielleicht ist bei Dir noch etwas ganz anderes faul bei dem Rebuild. Was zeigt denn der Ressourcen-Monitor fürs Volume an?

 

[ChRo]

Das System laggt erheblich, Reaktionszeiten von 3 sec in der Shell sind aktuell üblich.

Anbei die Daten:

-----------------------------------------------------------------------------------------------------
DS410j> cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sdc5[2] sdb5[1] sda5[0]
7809195264 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
[==========>..........] reshape = 50.3% (3929376060/7809195264) finish=314256.6min speed=205K/sec

md1 : active raid1 sdc2[4](S) sdb2[5] sda2[0]
2097088 blocks [4/1] [U___]
resync=DELAYED

md0 : active raid1 sdc1[2] sdb1[1] sda1[0]
2490176 blocks [4/3] [UUU_]

--------------------------------------------------------------------------------------------------
DS410j> top
Mem: 104428K used, 14052K free, 0K shrd, 2008K buff, 21296K cached
CPU: 10.6% usr 4.5% sys 0.0% nic 0.0% idle 83.9% io 0.1% irq 0.5% sirq
Load average: 11.16 6.68 4.50 1/200 14969
PID PPID USER STAT VSZ %MEM %CPU COMMAND
14948 3856 root D 31864 26.8 3.5 entry.cgi_SYNO.Core.System.Utilization[1].get
6322 1 root S 108m 93.8 0.4 scemd
3859 3854 root S < 50460 42.5 0.4 /usr/bin/httpd -f /etc/httpd/conf/httpd.conf-sys
7305 1 root S 25216 21.2 0.4 /usr/syno/sbin/snmpd -Ln -c /usr/syno/etc/snmpd.conf -p /var/run/snmpd.pid udp:161,udp6:161,tcp:161,tcp6:161
128 2 root SW 0 0.0 0.4 [kswapd0]
6998 1 root S 29548 24.8 0.2 /usr/bin/nmbd -D
25470 1 root S 21532 18.1 0.2 /usr/syno/sbin/synosnmpcd
6314 1 root S 11976 10.0 0.2 /usr/syno/sbin/synostoraged
15346 1 root S 5144 4.3 0.2 hostapd /etc/hostapd/hostapd-wlan0.conf
14941 14818 root R 4304 3.6 0.2 top
938 1 root S 2672 2.2 0.2 /usr/syno/sbin/dbus-daemon --session --fork --print-address
98 2 root SW 0 0.0 0.2 [kblockd/0]
25046 25031 http S 286m246.7 0.0 /usr/bin/httpd
14806 22207 root S 55156 46.4 0.0 sshd: root@pts/1

 

[dil88]

Ich dachte eigentlich mehr an den Ressourcen-Monitor im DSM, aber vielleicht ist das zu zäh. Wie sehen die numerischen SMART-Werte der Platten aus?

 

[ChRo]

 

[dil88]

Normal ist der SMART-Status teilweise auch bei Platten, die sich in den letzten Atemzügen befinden. Hilfreich wären Screenshots von den Daten, die Du nach Auswahl der Platte unter Integritätsstatus bekommst. Dort bitte das Fenster so groß ziehen, dass alle Werte zu sehen sind. Und das dann für alle drei Platten.

Edit: Sollte es Pakete geben, die Du nicht unbedingt brauchst, wäre es gut, Du würdest sie einmal deaktivieren, um zu schauen, ob mehr verfügbarer RAM hilft.

 

[ChRo]

Danke für den Hinweis, anbei die Smart Daten der Festplatte. Irgendwelche Pakete laufen auf dem Gerät nicht, es ist ein reines Backupsystem und der Hotspot für den Garten.

Speicher konnte ich nur über die Änderung des Stripe_cache freischafeln, Habe den Wert jetzt auf 512 gesetzt, die Änderung wird allerdings augenscheinlich nicht umgesetzt, zumindest bringt die Abfrage nicht den eingebenen Wert.

 

[dil88]

Die SMART-Werte sehen bis auf wenige High-Flys auf Platte 2 und 3 gut aus, daran sollte es nicht liegen. Wenn Du nicht die Archives hättest, würde ich zu einem Ticket bei Synology raten.

 

[ChRo]

The end

Zur Info: Habe zwischenzeitlich den in der Tat den "Stecker gezogen", und das SHR Raid komplett neu eingerichtet. Einen Abbruch der Volumeerstellung hat das Gerät komplett ignoriert. Sache insgesamt sehr merkwürdig. Das anschließende Formatieren aller Platten war in 3 Tagen (ca. 70h). Weiter gibt es nichts besonderes mehr zu berichten. Habe nunmehr 1 Volume mit 14,43 TB Datenvolumen das gerade mittels rsync abgeglichen wird.

Ich bete inbrünstig, das mir keine HD aus dem Verbund fliegt, deshalb habe ich dem Backupserver eine USV spendiert. Nochmals mache ich so eine Aktion nicht mit. Das ursprüngliche geplante spätere Aufstocken um noch eine Archiv Platte schenke ich mir definitiv. Vorher geht die DS410j in Rente.

In jedem Fall Danke für die Hilfe.