ungewöhnliche Prozessauslastung


Voss

Recommended Posts

Hallo zusammen,

 

ich beobachte seit einigen Wochen eine ungewöhnliche Auslastung eines Prozesses auf meinem Unraid-Server. Unter Werkzeuge --> Prozesse sieht es wie folgt aus:

 

root     32270 99.9  0.0   2460   756 ?        R    Mar26 14500:49 fuser -s /mnt/cache/backups/urbackup/linux-client/210314-1511/root/home/username/.steam/debian-installation/ubuntu12_32/steam-runtime/amd64/selinux

 

Man sieht, der Prozess scheint seit dem letzten Neustart des Servers (26.03.) durchgehend in Betrieb zu sein. Auf der Übersichtsseite sehe ich immer wieder einen Prozessorkern, welcher mit 100% ausschlägt.

 

Ich vermute, dass es irgendwas mit meiner Backupsoftware Urbackup, welche ich als Docker-Container laufen hab, Symlinks und dem Mover zu tun hat. Jedoch bin ich bezüglich einer Lösung hier schon mit meinem Latein am Ende :(

 

Hat jemand von euch einen Vorschlag, wie man dieses Problem der andauernden Prozessorauslastung beheben kann?

 

Wenn noch irgendwelche weiteren Informationen benötigt werden, kann ich diese gerne liefern :)

Link to comment

Nun ja. Dieser Container führt das Kommando aus. Das Kommando "fuser" dient dazu herauszufinden welche Prozesse eine Datei verarbeiten. Vielleicht eine Art Monitoring wegen Dateiänderungen?! Ist auf jeden Fall ungewöhnlich, dass die CPU Last so groß wird.

 

Der richtige Ansprechpartner wäre hier in jedem Fall Urbackup.

Link to comment

Danke für die Rückmeldung :)

 

Was mich nur irritiert, der Prozess bleibt so wie er ist bestehen, auch wenn der Container beendet wird. Mir sagt das, dass der Prozess vom Betriebssystem ausgeführt wird und da wiederrum sehe ich den "Datei-Mover" als Ursache. Ein weiteres Indiz, was ich anfangs vergessen hatte zu erwähnen, ist, dass ich in der Übersicht meines Arrays den Mover nicht manuell aktivieren kann, da er derzeit ausgeführt wird. Hier mal ein Screenshot dazu:

 

grafik.thumb.png.e7930a2da66cfe445c2b3d137fd1758d.png

 

Der Ordner "backups" ist wie folgt angelegt:

 

grafik.thumb.png.a539d37cb729ff439eee8a8f39eac731.png

 

Die Backupdateien, welche Urbackup anlegt liegen in einem Unterordner "urbackup" auf "backups". Bei einigen scheint der Mover ein Problem mit dem Verschieben zu haben, zumindest hängt er sich daran auf. Ich hatte daraufhin die Datei mal gelöscht, jedoch mit dem Ergebnis, dass er sich an der nächsten Datei aufhängt. Dieses mal ist es folgender sehr ähnlicher (diesmal der Überordner i386 und nicht amd64) Prozess:

 

root     18459  100  0.0   2460   760 ?        R    21:35  14:28 fuser -s /mnt/cache/backups/urbackup/linux-client/210314-1511/root/home/username/.steam/debian-installation/ubuntu12_32/steam-runtime/i386/selinux

 

Eine gelistete Ausgabe des Ordners zeigt mir, dass die Datei ein Symlink und eine sog. Archivdatei (?) zu sein scheint - die rote Schrift soll zumindest ein Indiz dafür sein. Da kenne ich mich leider nicht genug mit aus.

 

root@Ikarus:/mnt/cache/backups/urbackup/linux-client/210314-1511/root/home/username/.steam/debian-installation/ubuntu12_32/steam-runtime/i386# ls -la
total 16
drwxrwx--- 1 nobody users  50 Jul  9  2020 ./
drwxrwx--- 1 nobody users 340 Sep 29  2020 ../ 
lrwxrwxrwx 1 nobody users  98 Jul  9  2020 etc -> ../../../../../../../../root/home/username/.steam/debian-installation/ubuntu12_32/steam-runtime/etc 
lrwxrwxrwx 1 nobody users 104 Jul  9  2020 installed -> ../../../../../../../../root/home/username/.steam/debian-installation/ubuntu12_32/steam-runtime/installed/
lrwxrwxrwx 1 nobody users  98 Jul  9  2020 lib -> ../../../../../../../../root/home/username/.steam/debian-installation/ubuntu12_32/steam-runtime/lib/
lrwxrwxrwx 1 nobody users 107 Jul  9  2020 selinux -> ../../../../../../../../root/home/username/.steam/debian-installation/ubuntu12_32/steam-runtime/i386/selinux 
drwxrwx--- 1 nobody users  58 Jul  9  2020 usr/ 

 

Nur warum genau mag der Mover diese Dateien nicht?

 

Da dies kein Einzelfall zu sein scheint, bin ich gewillt, die Backups von Urbackup direkt auf das Array schreiben zu lassen, ohne vorher über den Cache zu gehen. Kennt hier jemand eine gute Methode die bereits vorhandenen Dateien des Verzeichnisses zu verschieben?

Oder ist das klassisch mit dem "mv"-Befehl möglich?

 

Edited by Voss
Link to comment

Was gibt das Kommando zurück?

fuser /mnt/cache/backups/urbackup/linux-paula/210314-1511/root/home/raphael/.steam/debian-installation/ubuntu12_32/steam-runtime/i386/selinux

 

Der Mover führt das wohl aus um zu prüfen ob eine Datei gerade verwendet wird und wenn das der Fall ist, wird die Datei nicht auf das Array verschoben. 

 

Ich vermute die hohe Last ist nur die Folge aus der Häufigkeit, mit der verschiedene Dateien geprüft werden.

Link to comment

Aber der Prozess bleibt ja konstant bei dieser einen Datei stehen. Wenn der Mover mehrere Dateien hintereinander prüfen würde, ok. Aber bei einer kleinen Datei über mehrere Tage/Wochen hinweg? Sieht für mich mehr nach einem Prozess aus der wiederholt vor die Wand fährt.

 

 

Gibt es eine Möglichkeit mir den Prozess über die Kommandozeile genauer anzusehen?

Edited by Voss
Link to comment

Hi,

 

bitte entschuldige die späte Antwort, war eine harte Arbeitswoche.

 

Der Status des Prozesses war in den beiden oberen Fällen "R".

 

root     18459  100  0.0   2460   760 ?        R    21:35  14:28 fuser -s /mnt/cache/backups/urbackup/linux-client/210314-1511/root/home/username/.steam/debian-installation/ubuntu12_32/steam-runtime/i386/selinux

 

 

Ich habe Dienstagabend jedoch den Server neu gestartet. Da der Mover immer wöchentlich am Montag loslegt, habe ich den Fehler bis jetzt noch nicht reproduzieren können. Seit ich den heute Mittag manuell angestoßen habe, läuft er erstmal ordnungsgemäß durch, braucht allerdings sehr lange. Ich warte jetzt mal die kommenden Tage ab und prüfe, ob/

wann sich der Prozess wieder erhängt.

 

 

EDIT: Der Prozess hing sich in der Nacht wieder an derselben Datei auf.
Ich habe nun auch diese mal gelöscht. Mit etwas Glück, waren es die beiden einzigen Dateien, die Probleme machten.

 

EDIT 2: So scheint es dann auch gewesen zu sein. Der Mover hat als solches im Backup-Ordner zwar sehr sehr langsam gearbeitet, es sind jedoch keine weiteren Dateien aufgetaucht, an denen er sich aufgehangen hat. Damit hat sich das Thema für mich erledigt. Vielen Dank @mgutt für deine Unterstützung :)

Edited by Voss
solved
  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.