CPU ausgelastet -wer/was lastet CPU aus? Wie herausfinden?

[DataCollector]

Hallo.

Seit knapp unter 2 Tagen pumpe ich Daten auf mein unraid.

(Disks wurden kurz vorher gelöscht und dann unraid mit xfs encrypted auf 11 HDD array ohne Parity neu erzeugt. Cache ist für alle Shares aus. Dazu ist eine NVME SSD für appdata, isos, system und domains drin.)

 

Hier benutze ich einmal Terminal rsync um viele Videos von einer Win10 Maschine über das Netzwerk zu ziehen und auf einem Share (realvideo auf Disk1-5) abzuspeichern. Da die Quelldateien auf dem WIn10PC in verschiedenen Verzeichnissen enthalten sind, starte ich nach einem kopierten Verzeichnis manuell das nächste. Deshalb schaue ich öfters auf den PC um zu sehen, wann ich den nächsten rsyncbefehl absetzen kann,

Ungefär so: rsync -avh "/mnt/remotes/QUELL1064_Z/VERZ1" "/mnt/user/realvideo"

Dann läuft gleichzeitig ein zweites Terminalfenster mit rsync um viele Dateien unterschiedlichster Größe zu kopieren (von vielen kleinen jpg Bildern und Textdateien bis zu mehrere GB grosse Images von Backups oder ISOs) von einer anderen Win10 Maschine über das Netzwerk auf Share (data auf Disk6-7). Auch hier sind es mehrer Quellverzeichnisse, deren Kopiervorgang ich manuell nacheinander anstoße.

Und als drittes habe ich im unraid-PC selber 3 SAS Festplatten als unmounted Device gemounted und kopiere von dort per ich777Docker/krusader auf ein Share (ae auf Disk 8-11).  Diese kopiere ich sequentiell. Erst SASDisk1 gemountet, dann alle Dateien/Verzeichnisse von SASDisk1 auf Share kopiert, dann SASDisk2 gemountet und Dateien markiert und per krusader auf Sahre kopiert. Aktuell ist SASDisk3 dran.

 

Zuletzt hatte ich heute Nachmittag gegen ca. 16 Uhr mal auf den PC geschaut und da lief alles erwartungsgemäß.

Als ich jetzt gegen 22 Uhr  wieder auf den steuernden PC schaue sehe ich im "Main" Tab nun Lese- & Schreibrate aller 12 Disks 0 MB/s. Verwundert schaue in die Terminalfenster: keine Fehlermeldung, keine Abbruchmeldung, die zeigten einfach, dass sie aktuell wohl jeweils eine Datei kopierten und bewegten sich nicht. Ich habe beide Terminalfenster dann geschlossen.

In den krusader geschaut und auch dort, sah es aus, als wenn er mitten drin sei eine Datei zu kopieren. Nach einer Wartezeit von einigen Minuten sah ich aber keine Veränderung und habe das noVNC Firefox Fenster (WebUI) des krusader geschlossen und den krusader Docker dann einige weitere Minuten später gestoppt.

Dann erst schaute ich bei Unraid in das Dashboard und sah, dass die CPU auf allen 4Kernen (+4HT) voll ausgelastet ist. (Screenshot siehe unten)

Dennoch bediente sich die per Firefox über LAN gesteuerte GUI flüssig. Ab und zu zuckten auch die CPU Anzeigen etwas, aber alles im Bereich sehr hoher Auslastung (fast konstant 100%)

nun schaue ich ueber eine halbe Stunde der Sache zu und klicke ein bisschen zwischen main und Dashboard hin und her. Nun auf einmal bekomme ich 504 Gateway Time-out und kann mich auch nicht mehr über die IP einloggen.

Also greife ich per KVMoverIP direkt auf die Bildschirmausgabe und USB Ports des etwas entfernt stehenden unraidPC zu und mit Tastendruck wacht auch die Konsolenanzeige auf. Ich kann mich per root + <passwort> einloggen. Dann löse ich einen Reboot aus, aber das wars. Es passiert seit dem nichts mehr. (Screenshot unten)

 

Ich werde wohl wirklich (aus der Ferne) Power abschalten und dann auch darüber wieder neu booten müssen.

 

Nun stellt sich mir die Frage: Wenn so etwas wieder passiert, wie bekomme ich heraus, welche(r) Verursache hier klemmen geblieben ist? Welche Mittel habe ich, wenn unraid selber sich noch bedienen läßt?

 

Edited July 14, 2021 by DataCollector
Disk Anzahl korrigiert

[mgutt]

2 hours ago, DataCollector said:

Dann löse ich einen Reboot aus, aber das wars. Es passiert seit dem nichts mehr. (Screenshot unten)

Dieses Problem hatte ich öfter wenn rsync noch arbeitet. Und zwar trennt Unraid beim Runterfahren alle Disks. rsync schreibt aber noch und wenn der Pfad zur Disk weg ist, schreibt rsync einfach weiter, erstellt also den Ordner neu, der eigentlich vorher eine gemountete Disk war und flutet damit lustig den RAM. In den Logs erscheint dann immer wieder, dass Unraid versucht die Disk zu unmounten, was aber fehlschlägt, weil der Mount ja schon längst gelöst wurde und nach kurzer Zeit ist der RAM voll und nichts geht mehr.

 

Aus dem Grund habe ich bei mir die Datei /boot/config/stop mit folgendem Inhalt erstellt (also "touch /boot/config/stop" ausführen und dann mit dem Config File Editor bearbeiten):

#!/bin/bash

# -------------------------------------------------
# Kill all rsync processes
# -------------------------------------------------
pkill -x rsync

 

2 hours ago, DataCollector said:

Wenn so etwas wieder passiert, wie bekomme ich heraus, welche(r) Verursache hier klemmen geblieben ist? Welche Mittel habe ich, wenn unraid selber sich noch bedienen läßt?

Für eine Analyse ist es in deinem Fall jetzt zu spät. Für den nächsten Fall solltest du dir merken wie man laufende Prozesse anzeigen lassen kann:

htop

 

Weiteres zur Abstürzen hatte ich hier geschrieben:

https://forums.unraid.net/topic/99393-häufig-gestellte-fragen/?tab=comments#comment-1008640

 

2 hours ago, DataCollector said:

"/mnt/user/realvideo"

Du willst ja meine ich, dass Unraid die Verteilregeln anwendet. Dabei opferst du einiges an CPU Leistung. Würdest du in den Global Share Settings die Disk Shares aktivieren, könntest du direkt auf /mnt/disk1/realvideo, /mnt/disk2/realvideo usw kopieren. Dann musst du dir aber überlegen wie viel auf welche Disk kopiert werden soll. Der Vorteil ist aber, dass die CPU Last deutlich sinkt. 30 bis 50% sind keine Seltenheit, gerade beim Schreiben. Da muss man abwägen ob Komfort oder Performance wichtiger ist. Manche wie @hawihoney arbeiten deswegen ausschließlich mit Disk Shares. Ich mache beides im Wechsel, je nach Bedarf. zB schreibe ich über 10G meist direkt auf den Cache statt über den User Share zu gehen. Auch erklärt in meinem Guide unter #3:

https://forums.unraid.net/topic/97165-smb-performance-tuning/

 

 

 

[DataCollector]

Hallo @mgutt

10 hours ago, mgutt said:

Dieses Problem hatte ich öfter wenn rsync noch arbeitet. Und zwar trennt Unraid beim Runterfahren alle Disks. rsync schreibt aber noch und wenn der Pfad zur Disk weg ist, schreibt rsync einfach weiter, erstellt also den Ordner neu, der eigentlich vorher eine gemountete Disk war und flutet damit lustig den RAM. In den Logs erscheint dann immer wieder, dass Unraid versucht die Disk zu unmounten, was aber fehlschlägt, weil der Mount ja schon längst gelöst wurde und nach kurzer Zeit ist der RAM voll und nichts geht mehr.

 

Okay. Das habe ich verstanden.

Ich hatte unter dem Tab Stats/System Stats nachgesehen aber alle 4 Graphen  blieben unverändert leer. vermutlich war der Prozess auch behindert/abgestürzt.

 

 

10 hours ago, mgutt said:

Aus dem Grund habe ich bei mir die Datei /boot/config/stop mit folgendem Inhalt erstellt (also "touch /boot/config/stop" ausführen und dann mit dem Config File Editor bearbeiten):

#!/bin/bash

# -------------------------------------------------
# Kill all rsync processes
# -------------------------------------------------
pkill -x rsync

 

Done.

ich vermute das ist nun sowas wie ein Batch unter Dos?

Laienfrage: Wie wende ich die dann an?

Zusätzliches Terminalfenster auf machen und stop tippen um dann alle laufenden rsync zu stoppen?

 

 

10 hours ago, mgutt said:

Für eine Analyse ist es in deinem Fall jetzt zu spät.

Das hatte ich auch vermutet. Deshalb meien Frage für die Zukunft. 🙂

 

10 hours ago, mgutt said:

Für den nächsten Fall solltest du dir merken wie man laufende Prozesse anzeigen lassen kann:

htop

Danke!

 

10 hours ago, mgutt said:

Du willst ja meine ich, dass Unraid die Verteilregeln anwendet.

Ja, denn sonst habe ich von meiner 10GBLan Anbindung keinen Nutzen. Es sind SMR Platten und die bremsen sonst massiv. So verteilt sich die Schreiblast gut.

 

10 hours ago, mgutt said:

Dabei opferst du einiges an CPU Leistung.

Etwas Leistung war mir klar und hatte ich auch ueber Stunden auch beobachtet. Ich teste ja chon seit Monaten. Aber dass es nun so hohe Last wird wundert mich. Ich kann es mir dadurch erklaeren, daß zusätzlich bei diesem testlauf encryption aktiviert ist. Aber daß ich damit einen I7-6700k an die Maximallastrenze treibe hätte ich jetzt nicht vermutet. Ich hatte immer im Hintrekopf, dass unraid nicht ganz so leistungshungrig ist.

Ist ja nicht so, als hätte ich da eine VM noch aktiv gehabt.

Und der krusader Docker sollte ja auch nur kopieren.

 

10 hours ago, mgutt said:

Würdest du in den Global Share Settings die Disk Shares aktivieren, könntest du direkt auf /mnt/disk1/realvideo, /mnt/disk2/realvideo usw kopieren.

Da befürchte ich aber, dass SMR zuschlägt und die Platten nach ca. 0,5-1h drauf schreiben (auch wegen der parallelen Lesezugriffe des Dateisystemes) auf nur noch 24MByte/s einbrechen. Zumindets kann ich sowas beobachten, wenn ich dann auf den Disks direkt mit krusader arbeite.

(siehe diverse vorherige tests). Diesesmal wollte ich es eben nichtvorher sortieren, sondern erst alles auf die Unraidmaschine kopieren und spaeter sortieren.

Wie ich es mache ist egal. Ich stosse auf allen Wegen immer wieder vor Probleme 😊

Aber deshalb teste ich es ja.

 

10 hours ago, mgutt said:

Der Vorteil ist aber, dass die CPU Last deutlich sinkt. 30 bis 50% sind keine Seltenheit, gerade beim Schreiben.

Ich vermute 30-50% pro Kopiervorgang?

Dann waren 3 gleichzeitige Vorgänge wohl etwas viel.

 

10 hours ago, mgutt said:

Da muss man abwägen ob Komfort oder Performance wichtiger ist.

 

Prio 1: Am Ende maximale Datensicherheit!

Prio 2: möglichst hohe Stabilität (keine Abstürze)

Prio 3: Weniger Strom verbrauchen als meine Hardwareraid basierten Windowsmaschinen

Prio 4: Geschwindigkeit

Prio 5: Komfort

Prio 6: Spass an der Sache

😀

 

10 hours ago, mgutt said:

Manche wie @hawihoney arbeiten deswegen ausschließlich mit Disk Shares. Ich mache beides im Wechsel, je nach Bedarf.

Da ich bei dem angestrebten spaeteren System (ich schrieb es ja schon mal 300-400TB) alles schön in Unterverzeichnissen sortiert in einem Share haben will, wäre die direkte Nutzung von Disk Shares weniger in meinem Sinne. Aber auch das muß ich erst einmal ausprobieren.

 

10 hours ago, mgutt said:

zB schreibe ich über 10G meist direkt auf den Cache statt über den User Share zu gehen. Auch erklärt in meinem Guide unter #3:

Später im Wirkbetrieb werde ich den Cache auch zuschalten, aber bei den intialen Test würde ich den SSD Cache kaputtschreiben, deshalb nutze ich den zur Zeit nicht

 

[mgutt]

29 minutes ago, DataCollector said:

Laienfrage: Wie wende ich die dann an?

Wenn im Ordner Config eine Datei "stop" liegt, führt Unraid diese automatisch bei einem Reboot / Shutdown aus.

 

Das ist das selbe wie mit der "go" Datei, die beim Start des Servers ausgeführt wird.

 

31 minutes ago, DataCollector said:

So verteilt sich die Schreiblast gut.

Es kommt auf deine Ordnerstruktur an, aber du könntest ja problemlos mehrere rsync parallel ausführen, die auf unterschiedliche Disks schreiben. Also zb Filme/A auf Disk 1 und Filme/B auf Disk 2. Eben so wie es von der Gesamtgröße eines Ordners Sinn macht.

 

33 minutes ago, DataCollector said:

Ich vermute 30-50% pro Kopiervorgang?

Dann waren 3 gleichzeitige Vorgänge wohl etwas viel.

Führe einfach mal htop aus, während 3 laufen. Dann addiere alle SHFS Prozesse. Das sind die, die nur kommen, wenn man auf /mnt/user/bla schreibt.

 

34 minutes ago, DataCollector said:

Später im Wirkbetrieb werde ich den Cache auch zuschalten, aber bei den intialen Test würde ich den SSD Cache kaputtschreiben, deshalb nutze ich den zur Zeit nicht

Das ist auch absolut OK. Ich meine auch später, dass man gezielt auf /mnt/cache/sharename schreiben kann, ohne einen SHFS Prozess auszulösen.

 

Wie gesagt. Addiere mal die Auslastung. Du wirst dich wundern was da alles ackert.