Moin zusammen,

nach ein paar Tagen des herum Probierens, finde ich einfach den Fehler nicht. Ich habe ein recht Potentes unRAID System schon seit fast einem Jahr laufen. Aber seit ca. 1 Woche dreht die CPU-Last immer wieder hoch. Ich betreibe eine VM und eine reihe von Docker. Aber alles nichts ungewöhnliches. Ich habe sogar das Docker img gelöscht und alle Docker neu erstellt. Ich habe aber das Gefühl, dass es an unRAID selbst liegt.

Ich nutze die 7.0.0-beta.3, habe aber auch schon ein Downgrade auf beta 2 gemacht, ohne Änderung.

Eine Zeitlang hatte ich keine Paritäts Platte, da sie kaputt war. Nach dem ersetzen der Platte, ging es glaube ich los. Kann auch 1-2 Tage später gewesen sein.

 

Ich bin jetzt auch kein Laie und weis eigentlich was ich hier mache, aber ich finde einfach den Grund nicht. Bemerkt habe ich das Problem eigentlich auch erst durch meine Monitoring Software, welche fast in Minuten Takt meldet, dass der "scrypted" Docker, bzw. die Webseite, nur sehr schwer erreichbar ist. Bis hin zu kurzen ausfällen wo dann für ein paar Sekunden gar nichts mehr geht. Ich nutze "scrypted" auch nicht erst seit gestern und glaube auch nicht das dies das Problem ist, sondern mehr "das Opfer" was unter der hohen Systemlast leidet.

 

Ich habe mal meine Diagnostics angehängt. Das erstellen der Datei hat auch 2-3 Minuten gedauert. Kommt mir etwas lang vor.

smarthomeserver-diagnostics-20241014-1939.zip

Hallo Pardasus

Dein Syslog ist voller routing/NTP Meldungen, kannst du dir das erklären? Dies scheint mir irgendwie nicht normal und könnte an einem instabilen Netzwerk liegen.

 

Entweder ist das ebenfalls die Folge von deinen CPU Aussetzern oder das Problem an den Unterbrüchen an sich..

Ich kenne das Fehlerbild jetzt nicht direkt, würde aber auf eine Fehlkonfiguration im Netzwerk tippen..

 

Grüsse

9 hours ago, Pardasus said:

Ich habe mal meine Diagnostics angehängt. Das erstellen der Datei hat auch 2-3 Minuten gedauert. Kommt mir etwas lang vor.

 

zu den angemerkten Themen von @Amane

 

der *multiple* Fehler ist nicht tragisch, nur nervig, Änderung am ntpd ... spammed etwas das log, fix kommt mit der nächsten beta.

 

siehe hier

 

 

hat aber nichts mit den vielen Einträgen hierzu zu tun

 

Oct 14 19:29:32 SmartHomeServer dhcpcd[1942]: br0: changing route to fd53:e506:249e::/64 via fe80::1730:50bc:4c5e:4204
...

 

hier mal gefragt, was für Netzwerk Hardware nutzt du ? Fritz, unify, ... ?

 

weil, anscheinend steht bei Dir Docker br auf IPVLAN ... das vertragen einige nicht ... Dienste sind dann immer schwer zu erreichen ...

würde ich mal mit macvlan testen, dann hat jeder Docker seine eigene mac

 

Thema CPU Last, denke das wird nicht das große Problem sein, deine HA VM braucht halt ...

 

 

und dein control Thema .. node ...ist aber auch bekannt da dies permanent im System abfrägt usw ...

 

Erreichbarkeit, teste mal macvlan, je nachdem von welcher Version du kamst ... wurde IPVLAN als Standard mal eingeführt, aber ist kritisch mit
diverser Netzwerk Hardware, daher würde ich immer macvlan empfehlen.

9 hours ago, Pardasus said:

Ich habe mal meine Diagnostics angehängt. Das erstellen der Datei hat auch 2-3 Minuten gedauert. Kommt mir etwas lang vor.

 

Mir kommt es nicht lang vor.

Egal ob mein System mit nur 8 oder mein System mit 26 Festplatten: Da unraid diese Festplatten andrehen (Spinup) muß um auch die Smartangaben einzufügen dauert das schon mal etwas.

Auch werden (wenn ich es richtig sehe) die Daten auf dem USB Stick gesammelt um sie dann zu komprimieren und als download dem Browser anzubieten.

Es kommt also auch die (Schreib)geschwindigkeit des USB Stick hinzu.

 

Ein Flash-Backup des USB Bootstick (bei dem nicht einmal die Smartwerte der Festplatten gesammelt werden müssen) dauert ja auch etwas.

Erstmal danke für eine mühe 🙂 @alturismo ich hatte es bewusst auf IPVLAN gestellt, um zu sehen ob es damit evtl. besser wird. Sonst habe ich immer macvlan an. Habe es nun auch wieder aktiviert. Als Netzwerk verwendet ich Unifi. 

 

Mein System besteht aus einen Pool von 3x 2TB Platten, wovon eine die Paritätsplatte ist. Diese ist vor ca. 1 Monat ausgefallen und ich habe das System ohne weiter laufen lassen. Vor ca. einer Woche habe ich dann vom Hersteller eine neue bekomme. Diese habe ich eingebaut und nun sind es wieder drei. Ich bin mir nicht 100%ig sicher, aber es könnte sein das es genau dann angefangen hat. unRAID hat gerade ein Parität-Check gestartet und sagt, er brauch zwischen 30-60 Tagen, teilweise geht es auf 100+ Tage hoch 😮vielleicht stimmt was mit den Platten nicht?

 

EDIT: wenn ihr jetzt keine Ideen mehr habt, werde ich alle Daten auf mein Backup unRAID System verschieben und das Array einmal komplett neu aufbauen (Partition löschen etc.)

 

Ich habe gerade noch mal die Diagnostics erstellt, das hat nun nur ein paar Sekunden gedauert.

smarthomeserver-diagnostics-20241015-1955.zip

Edited October 15, 20241 yr by Pardasus

1 hour ago, Pardasus said:

 ich hatte es bewusst auf IPVLAN gestellt, um zu sehen ob es damit evtl. besser wird.

nope ... auch unter Unify sind issues bekannt mit ipvlan ...

 

ist denn der bond mit 4 Netzwerkkaten bewusst so eingerichtet ? hast du tatsächlich alle 4 Ports im Verbund aktiv ?

 

wenn Nein, konfigurier das mal um, dein Netzwerk produziert halt viele Fehler

Ich habe vier Netzwerkkarten eingerichtet? Die Hardware hat zwei, wovon ich nur eine nutze.

 

Das kommt mir hier aber etwas komisch vor. Woher kommt das shim-br0? Und bei IPv6 sieht das auch irgendwie doppelt aus.

(ich brauche IPv6 da ich vieles über Matter laufen lasse und Home Assistant seitdem besser mit den Geräten Kommuniziert)

8 hours ago, Pardasus said:

Ich habe vier Netzwerkkarten eingerichtet? Die Hardware hat zwei, wovon ich nur eine nutze.

 

vergiss es, man sollte wenn man nicht fit ist parallel ... war ein anderer Thread hier  mein Fehler, sorry für die Verwirrung

 

Thema ipvlan sollte zumindest das Thema Erreichbarkeit fixen, aber warum dein disk speed so langsam ist ...

sehe ich jetzt nichts in den logs.

 

Hast du mal Parity Check ausgemacht und lokal isk speed getestet ? einfach mal kopiert von disk zu disk oder cache <> disk/s

12 hours ago, alturismo said:

vergiss es, man sollte wenn man nicht fit ist parallel ... war ein anderer Thread hier  mein Fehler, sorry für die Verwirrung

 

Thema ipvlan sollte zumindest das Thema Erreichbarkeit fixen, aber warum dein disk speed so langsam ist ...

sehe ich jetzt nichts in den logs.

 

Hast du mal Parity Check ausgemacht und lokal isk speed getestet ? einfach mal kopiert von disk zu disk oder cache <> disk/s

Kein ding  hatte mich schon gewundert 😄

 

Aber wir kommen der Sache näher. Die Performance der Platten ist absolut unterirdisch und bewegt sich in kb/s Bereich. Ich habe noch zwei NVMe als Cache Pool, der ist weiterhin super schnell. Aber irgendwas muss da passiert sein, als ich die Paritätsplatte wieder neu hinzugefügt habe. Nun könnte ich die Daten abziehen und auf mein unRAID Backup-System schieben, aber wenn das so langsam ist wird das Monate dauern. Bin gerade etwas ratlos.

 

p.s.: ein S.M.A.R.T Test verlief fehlerfrei.

Edited October 16, 20241 yr by Pardasus

1 minute ago, Pardasus said:

ist absolut unterirdisch und bewegt sich in kb/s Bereich.

oha

 

naja, ich würde zum Test

 

1/ Parity abbrechen

2/ Neustart

3/ speed Tests mal lokal machen, von zu cache nvme / disk/s

 

um einschätzen zu können was da Sache ist ...

So, ich bin wieder schlauer geworden.  Ich habe die Paritätsplatte mal entfernt und zack, alles läuft wieder wie es soll. Dann habe ich die Partition gelöscht und sie erneut hinzugefügt. Als die Parität dann wiederhergestellt wurde, hat er die 1h noch normal schnell gearbeitet, um dann wieder in den kb Speed Bereich zurück zu fallen. Also habe ich sie erst mal wieder entfernt und werde nun meine Daten mal verschieben. Danach das gesamte Array Platt machen und neu aufbauen.

44 minutes ago, Pardasus said:

hat er die 1h noch normal schnell gearbeitet, um dann wieder in den kb Speed Bereich zurück zu fallen.

vielleicht hat auch nur die Platte einen weg ... ? hab ich auch mal gehabt, seit die Platte getauscht wurde, alles ok.

3 hours ago, Pardasus said:

Als die Parität dann wiederhergestellt wurde, hat er die 1h noch normal schnell gearbeitet, um dann wieder in den kb Speed Bereich zurück zu fallen.

 

Ich habe jetzt nicht alles gelesen. Aber könnte es sein, daß Du eine SMR Festplatte an der Stelle verwendest?

On 10/18/2024 at 1:46 AM, DataCollector said:

 

Ich habe jetzt nicht alles gelesen. Aber könnte es sein, daß Du eine SMR Festplatte an der Stelle verwendest?

Das kann ich dir gar nicht genau sagen. Im Datenblatt der Festplatte steht davon nichts. Allerdings lief das System ein halbes Jahr, mit den Platten, fehlerfrei. Dann ist die erste Platte ausgestiegen und wurde getauscht. Jetzt sieht es fast so aus, als wäre die nächste Platte defekt. Ein kurzer SMART-Test war fehlerfrei. Der erweiterte Test läuft nun aber schon 24h und hängt seit 12h bei 90% fest. Ich habe diesen bei einer Platte einmal angeworfen. Tja, ich werde den Test noch bei den anderen machen, aber es sieht so aus als wäre die nächste WD Blue HDD defekt. Dabei habe ich extra auf HDD gesetzt und nicht auf SSD damit sie länger halten...

Edited October 19, 20241 yr by Pardasus

18 minutes ago, Pardasus said:

Das kann ich dir gar nicht genau sagen. Im Datenblatt der Festplatte steht davon nichts.

 

Wenn Du die jeweiligen Typenbezeichnungen benennst, könnte man ja mal nachschauen ob da SMR zwischen ist.

 

 

Das sind 3x WD20SPZX-22UA7T0. Ich konnte im Netz nichts dazu finden.

1 hour ago, Pardasus said:

Das sind 3x WD20SPZX-22UA7T0. Ich konnte im Netz nichts dazu finden.

https://geizhals.de/western-digital-wd-blue-mobile-2tb-wd20spzx-a1776586.html

 

Western Digital WD Blue Mobile 2TB, 512e / 2.5" / SATA 6Gb/s
(WD20SPZX)

 

Kapazität 2TB (entspricht ca. 1862.65GiB bzw. 1.82TiB, weiterführende Informationen hierzu) 
Formfaktor 2.5" 7mm
Drehzahl 5400/min 
Cache 128MB 
Aufnahmeverfahren Shingled Magnetic Recording (SMR), Drive Managed SMR 
 

Langsam drehende Festplatten mit SMR und einem überschaubaren Cache.

Mich wundert nicht, wenn die langsam sind und aufgrund von SMR nach dauerhaften Beschreiben (Parityerstellung) noch langsamer werden.

14 minutes ago, DataCollector said:

https://geizhals.de/western-digital-wd-blue-mobile-2tb-wd20spzx-a1776586.html

 

Western Digital WD Blue Mobile 2TB, 512e / 2.5" / SATA 6Gb/s
(WD20SPZX)

 

Kapazität 2TB (entspricht ca. 1862.65GiB bzw. 1.82TiB, weiterführende Informationen hierzu) 
Formfaktor 2.5" 7mm
Drehzahl 5400/min 
Cache 128MB 
Aufnahmeverfahren Shingled Magnetic Recording (SMR), Drive Managed SMR 
 

Langsam drehende Festplatten mit SMR und einem überschaubaren Cache.

Mich wundert nicht, wenn die langsam sind und aufgrund von SMR nach dauerhaften Beschreiben (Parityerstellung) noch langsamer werden.

Trotzdem sollten sie sich nicht in kb Bereich bewegen, bei der Datenübertragung. Ich habe nun die Vermutlich defekte Platte entfernt und alles läuft wieder normal und die Datenübertragunsrate lieg bei um 80-100MB/s. Hätte aber nie gedacht, dass eine "halb" defekte Festplatte zu einer stark erhöhten CPU-Last führt. 

 

Ich habe mich damals bewusst für die 2,5" entschieden, da ich alle Platten extern betreiben muss. Mein Mini-PC hat nur platz für 2x NVMe. Der Speed reich mir völlig, bei den HDDs. Es werden nur drei Video Streams drauf gespeichert und der rest an Daten liegt da eigentlich nur rum. Die NVMe, die sind wichtig für mich. Da laufen alle Docker und die VM drauf.

4 minutes ago, Pardasus said:

dass eine "halb" defekte Festplatte zu einer stark erhöhten CPU-Last führt. 

das ist sicher i/o wait ... und wie erwähnt, hate ich auch mal hier, die Platte liegt sogar noch hier, keine Fehler, kein ...

 

bis ich darauf kam ... war dann am Ende der speed Test mit copy von / zu cache und da war klar welche Platte ein Problem hat

58 minutes ago, Pardasus said:

Trotzdem sollten sie sich nicht in kb Bereich bewegen, bei der Datenübertragung. Ich habe nun die Vermutlich defekte Platte entfernt und alles läuft wieder normal und die Datenübertragunsrate lieg bei um 80-100MB/s. Hätte aber nie gedacht, dass eine "halb" defekte Festplatte zu einer stark erhöhten CPU-Last führt. 

Wenn ich meine Seagate Archive v2 8TB (ST8000AS0002) dauerhaft am Stück mit Daten beschreibe, diese schon vorher Daten enthielten, gehen die auch zwischenzeitlich soweit runter. Es hängt eben davon ab, ob sie vorher leer waren oder sich da mit vorhandenen Datenschnipseln um die Position streiten müssen.

Und das sind etwas flottere 3,5inch Modelle (aber ja, sehr viel flotter drehen die auch nicht).

Beachte, daß bei Parityaktionen (aber nicht bei der Ersterzeugung) auch noch die Kopfbewegungen dazu kommen.

Bei der parityerstellung über viele festplatten hinweg ist die Synchronisation der mit den anderen Festplatten noch bremsend. Nicht jede Festplatte hat immer rechtzeitig den selben Sektor unter ihrem Kopf.

 

58 minutes ago, Pardasus said:

Ich habe mich damals bewusst für die 2,5" entschieden, da ich alle Platten extern betreiben muss. Mein Mini-PC hat nur platz für 2x NVMe. Der Speed reich mir völlig, bei den HDDs.

Extern.

Bitte nicht USB und dann bitte auch nicht alle über den selben USB Kontroller mit Hub.

 

EDIT:

Ich habe mir jetzt aus Neugier Deine diagnostics angesehen.

 

ZOTAC -ZBOX-MI648/MI668
Egal welches der beifden Modelle ich bei Geizhals ansehe: gar keine SATA Ports (ausser die Fähigkeit eines M.2).
Auch sehe ich in der Auflistung keine SATA Kontrollerkarte.

 

Dafür aber 3x WD20SPZX (2,5inch SMR). Die laufen dann wohl bestimmt über USB.

USB im Array wird nicht wirklich empfohlen.

Deine Probleme können auch (zusätzlich) daher rühren.

Achja, Dein NVMe Pool scheint mit btrfs zu laufen.

Edited October 19, 20241 yr by DataCollector
Diagnostig gesichtet

36 minutes ago, DataCollector said:

Wenn ich meine Seagate Archive v2 8TB (ST8000AS0002) dauerhaft am Stück mit Daten beschreibe, diese schon vorher Daten enthielten, gehen die auch zwischenzeitlich soweit runter. Es hängt eben davon ab, ob sie vorher leer waren oder sich da mit vorhandenen Datenschnipseln um die Position streiten müssen.

Und das sind etwas flottere 3,5inch Modelle (aber ja, sehr viel flotter drehen die auch nicht).

Beachte, daß bei Parityaktionen (aber nicht bei der Ersterzeugung) auch noch die Kopfbewegungen dazu kommen.

Bei der parityerstellung über viele festplatten hinweg ist die Synchronisation der mit den anderen Festplatten noch bremsend. Nicht jede Festplatte hat immer rechtzeitig den selben Sektor unter ihrem Kopf.

 

Extern.

Bitte nicht USB und dann bitte auch nicht alle über den selben USB Kontroller mit Hub.

 

EDIT:

Ich habe mir jetzt aus Neugier Deine diagnostics angesehen.

 

ZOTAC -ZBOX-MI648/MI668
Egal welches der beifden Modelle ich bei Geizhals ansehe: gar keine SATA Ports (ausser die Fähigkeit eines M.2).
Auch sehe ich in der Auflistung keine SATA Kontrollerkarte.

 

Dafür aber 3x WD20SPZX (2,5inch SMR). Die laufen dann wohl bestimmt über USB.

USB im Array wird nicht wirklich empfohlen.

Deine Probleme können auch (zusätzlich) daher rühren.

Achja, Dein NVMe Pool scheint mit btrfs zu laufen.

Ich habe das System nun schon seit über ein Jahr mit den externen HDDs (USB). Läuft absolut einwandfrei. Auch die Performance ist mehr als ausreichend. Hatte nur vorher SSDs in den USB-Gehäusen. Habe die dann vor ca. 190 Tagen gegen HDDs getauscht und vor 1 Monat ist mir eine davon kaputt gegangen. Wurde nicht mehr erkannt und hat klack Geräusche gemacht. Das jetzt noch eine defekt ist, ist schon sehr ärgerlich. Aber sonst kann ich mich absolut nicht beklagen. Wie schon geschrieben, nutze ich die Hauptsächlich zum Speichern von Daten. Die ganze "action" findet auf den internen NVMe´s statt. 

 

Was spricht beim NVMe Pool gegen btrfs ? Muss zugegen, da kenne ich mich nur sehr oberflächlich aus.

 

Wenn sich jetzt noch gefragt wird "Warum nutzt er bitte USB Laufwerke?!"... na, wegen der Optik

Links Produktiv, rechts das Backup-System. Denn, was bringen mir Datenbackups, wenn die Hardware kaputt geht  so kann ich direkt auf den ersatz Rechner umstellen. Die Synchronisation der Daten zwischen den Rechner, findet über "Syncthing" statt.

Edited October 19, 20241 yr by Pardasus

17 hours ago, Pardasus said:

Ich habe das System nun schon seit über ein Jahr mit den externen HDDs (USB). Läuft absolut einwandfrei. Auch die Performance ist mehr als ausreichend. Hatte nur vorher SSDs in den USB-Gehäusen. Habe die dann vor ca. 190 Tagen gegen HDDs getauscht und vor 1 Monat ist mir eine davon kaputt gegangen.

 

Der physikalische Schaden einer Festplatte hat vermutlich nichts direkt mit USB zu tun (obwohl eine unzureichende Stromversorgung über USB dann doch eine Ursache sein kann). Es sieht mir nicht so aus, als wenn der erkennbare Hub unten rechts auf dem Bild eine zusätzliche Stromversorgung hat.

1x USB-C Input und 4mal USB Output könnte bei 3 Festplatten (und dem einzelnen USB Stick) schon mehr als grenzwertig sein).

Array über USB. Es ist bekannt, daß das Probleme machen kann, deshalb wird es auch nicht empfohlen. Da bin ich raus.

 

 

17 hours ago, Pardasus said:

Was spricht beim NVMe Pool gegen btrfs ? Muss zugegen, da kenne ich mich nur sehr oberflächlich aus.

 

Es gibt mir hier viel zu viele Problemmeldungen, die mit btrfs zusammen hängen. Deshalb mache ich da einen Bogen rum.

Edited October 20, 20241 yr by DataCollector
kleine Anpassung

16 hours ago, Pardasus said:

Wenn sich jetzt noch gefragt wird "Warum nutzt er bitte USB Laufwerke?!"... na, wegen der Optik

 

schön gemacht, aber schreib in Zukunft bitte direkt dazu "USB disks" ... dann können so Leute wie ich direkt aussteigen, kann gut gehen, meist aber wird es damit Issues geben ... du sagst ja selbst, vorher SSD in USB, jetzt HDD in USB ... siehe da, 2 Platten schonmal defekt ... endet in Array Ausstieg, unterirdische Geschwindigkeiten, usw usw ...

 

USB ist nun mal leider nicht dafür gemacht, die ganzen Mini, Micro, ... PC's ... schön und gut, aber als perm. data storage Lösungen ... immer kritisch.

Wenn du damit zufrieden bist, perfekt, aber erwarte hierzu wenig bis gar keinen support  da bekanntermaßen kritisch

 

Thema btrfs filesystem, bitte einlesen zu scrub ... btrfs kann gut gehen, aber als single disk device wird auch hier eher xfs empfohlen (robuster), gerade wenn Systeme mal aussteigen oder hart neu gestartet werden müssen ... steigt das FS btrfs gerne mal mit aus ... dazu gibt es sicherlich 100+ Einträge hier im deutschen Part schon

 

wobei man sagen kann, es gibt Systeme da läuft das unkritisch, daher ... wenn noch nie da etwas aufgetreten ist, passt.

@DataCollector

Bei der Stromversorgung über den USB-Hub könntest du recht haben. Es besteht die Möglichkeit diesen USB-Hub zusätzlich mit Strom zu versorgen. Das habe ich mal gemacht und nun hängt da noch ein Netzgerät dran.

 

Das btrfs hat mir unRAID damals eingerichtet. Ich habe nur die Platten hinzugefügt. Dies funktioniert aber bis jetzt absolut zuverlässig und fehlerfrei.

 

@alturismo

Das ist mit USB-Platten Problem gibt, war mir nicht bekannt. Deshalb habe ich es auch gar nicht erwähnt. Hatte auch bis jetzt nie Problem damit. Auch das zweit System läuft mit der gleichen Konfiguration komplett fehlerfrei und Performant.

 

Wie ich oben schon zu DataCollector geschrieben habe, hat mir unRAID die Platten als btrfs so Partitioniert und Formatiert. Ich dachte mir damals, wenn unRAID das vorgibt, wird es schon das richtige sein. Aber gut zu wissen, falls ich da mal Probleme mit bekommen sollte. Es gab auch schon 2-3x wo sich unRAID aufgehängt hat und ich hart ausschalten musste. Aber das btrfs hat mir das nie übel genommen.

 

Aber gut, mein Rechner läuft wieder wie er immer lief. Mehr als ausreichend schnell und ohne Fehlermeldung, nachdem ich die HDD entfernt habe. Bei den anderen mache ich noch ein Ausführlichen Smart-Test um sicher zu gehen.

 

Danke für eure Unterstützung 🙂