Sehr hoher "htop"-Wert von "Load average"

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • 8GB, Bullseye, Nextcloud, Postgresql, Apache2.


    Ich habe immer wieder die Situation, dass ich die Funktion "Einstellungen/System" von Nextcloud nicht aufrufen kann. Entweder wird das Laden ziemlich rasch abgebrochen (Ladeanzeige verschwindet), oder der Browser bricht nach langem Warten mit einer Fehlermeldung ab. Einträge in einem Log konnte ich bisher nicht finden. Alle anderen Funktionen sind uneingeschränkt nutzbar.

    "Load average" von "htop" zeigt dann jeweils einen sehr hohe Wert (bis >20) an. Ich weiss zwar nicht, was da gemessen wird, aber der Wert irritiert mich, weil die Prozessorkerne nur schwach asugelastet sind und er nach einem Neustart üblicherweise bei ±1 liegt. Wenn nur apache neu gestartet wird, sinkt der Wert bis gegen 4, um anschliessend langsam wieder anzusteigen. Das Problem der nicht ladenden Webpage wird dadurch aber nicht behoben.

    Bis jetzt konnte ich das jeweils nur durch einen reboot wieder herstellen.

    Ich habe nicht benötigte Softwarepackages und Dienste entfernt und andere Dienste neu gestartet. Nützt alles nichts.

    Falls jemand eine Idee hat, was ich noch tun könnte, würde mich ein entsprechender Hinweis freuen.

    Vielen Dank.

  • Falls jemand eine Idee hat, was ich noch tun könnte, ---

    Versuch mal mit einer niedrigen swappiness:

    Code
    vm.swappiness = 1

    in der /etc/sysctl.conf bzw.

    Code
    sudo sysctl -w vm.swappiness=1

    in der Kommandozeile.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • thx hyle

    Wenn ich den Beitrag in Wikipedia richtig verstehe, deutet das auf eine lange Schlange von Prozessen hin, die auf die Verarbeitung warten. Dann verstehe ich um so weniger, warum denn die Auslastung der Prozessorkerne nahe bei Null liegt.


    thx rpi444

    Code
    vm.swappiness = 1

    Ist bereits so konfiguriert

  • Danke hyle

    Ich habe zu Testzwecken die Volltextsuche stillgelegt. Zur Zeit ist "Load average" <1 und die Speicherbelegung 1.7GB.

    Die Situation, dass "Einstellungen/System" nicht öffnet, treffe ich immer morgens an, ist aber auch schon tagsüber vorgekommen. Dazu ist zu sagen, dass nachts ein Backup (raspiBackup von framp; shell script, rsync, NTFS auf NAS ) läuft. Dienste werden vor und nach dem Backup stillgelegt und wieder in Betrieb genommen und ich wüsste nicht, wo ich hier einen Zusammenhang sollte suchen müssen.

    Ich warte jetzt mal morgen früh ab und berichte dann wieder.

    Danke für die Unterstützung.

  • Gestern habe ich einen Nextcloud-Upgrade installiert. Der behebt das Problem aber nicht.

    Ich werde jetzt wohl nach dem Backup standardmässig einen reboot konfigurieren. Das gefällt mir aber gar nicht. Lieber hätte ich die Ursache des Problems gefunden und behoben.

    Vielen Dank für die Unterstützung.

  • Ich habe mich schon oft gewundert über die Tatsache, dass NC in «Einstellungen/System» den Share «/backup» anzeigt, es aber nie mit «raspiBackup» in Zusammenhang gebracht:

    Nun scheint klar zu sein, der Share wird vom Script nicht getrennt.

    Weil nach dem Backup das NAS stillgelegt wird, ist der Share auf dem Pi zwar noch vorhanden, aber die Daten können nicht abgerufen werden und «Einstellungen/System» öffnet nicht.

    Ich habe zu Testzwecken im Script alle Aufrufe von «umount» ersetzt durch «umount -l». Das könnte den Nachteil haben, dass der Share gar nie getrennt und das Script nie beendet wird. In meinem Test ist das Script zwar bis zum Ende durchgelaufen, aber nicht fehlerfrei:

    Code
    --- RBK0260I: Dynamischer umount von /mnt/qnap wird vorgenommen.
    --- RBK0017I: Backup erfolgreich beendet.
    --- RBK0010I: *: raspiBackup V0.6.6.1 (6c10535) Mi 30 Mär 2022 15:23:02 CEST beendet mit Returncode 0.
    --- RBK0167I: Eine eMail wird versendet.
    /usr/local/bin/raspiBackup: Zeile 1716: /mnt/qnap/*/*-rsync-backup-20220330-144504/raspiBackup.log: Datei oder Verzeichnis nicht gefunden
    /usr/local/bin/raspiBackup: Zeile 1717: /mnt/qnap/*/*-rsync-backup-20220330-144504/raspiBackup.log: Datei oder Verzeichnis nicht gefunden
    --- RBK0026I: Debug Logdatei wurde in /mnt/qnap/*/*-rsync-backup-20220330-144504/raspiBackup.log gesichert.
    /usr/local/bin/raspiBackup: Zeile 1722: /mnt/qnap/*/*-rsync-backup-20220330-144504/raspiBackup.log: Datei oder Verzeichnis nicht gefunden
    /usr/local/bin/raspiBackup: Zeile 1725: /mnt/qnap/*/*-rsync-backup-20220330-144504/raspiBackup.log: Datei oder Verzeichnis nicht gefunden

    Aber der Share ist danach getrennt:

    Wenn das Script nach dem trennen der Verbindung noch versucht auf dem Share etwas zu lesen oder zu schreiben, sind die Fehler aber nachvollziehbar. Die Fehler sind vorher wohl nicht aufgetreten, weil der Share gar nie getrennt wurde.

  • Sehr gute Analyse bavoub:thumbup:

    Wie ich sehe nutzt Du nicht den aktuellsten Code von 0.6.6.1. Es gab zwischenzeitlich einen raspiBackup Nutzer der hatte auch umount Probleme wenn er DYNAMIC_MOUNT nutzte und fand eine gute Loesung . Es ist in der aktuellsten 0.6.6.1 gefixed und natuerlich auch in der Beta 0.6.7 drin.

    Benutzt Du dynamic mount?

  • ... morgen früh ... :)

    Das Script ist durchgelaufen. Allerdings stehen auch hier in der Konsole nach unmount und versenden der eMail Meldungen wegen nicht auffindbarer "raspiBackup.log"-Datei. Am Speicherort fehlt die Datei tatsächlich. Kann es sein, dass nach dem unmount noch versucht wird die Datei rüberzuschieben?

    Zeilen 1716, 1717, 1722, 1725

  • Kann es sein, dass nach dem unmount noch versucht wird die Datei rüberzuschieben?

    Nein. Das Rueberschieben der Logdatei ins Backupverzeichnis geschieht ganz zum Schluss kurz bevor der umount der Backuppartition stattfindet.

    Zeilen 1716, 1717, 1722, 1725

    Sind das immer noch die Zeilennummern? Im aktuellen Stand von raspiBackup 0.6.6.1 werden an der Stelle Messages definiert :conf: Kann es sein dass Du noch den alten Stand aufrufst? So sollte die Ausgabe bei Dir aussehen:

    Code
    raspiBackup.sh --version
    Version: 0.6.6.1 CommitSHA: b4749b7 CommitDate: 2022-03-08 CommitTime: 18:19:59

    Den aktuellen Stand der 0.6.6.1 holst Du Dir normalerweise mit

    Code
    sudo raspiBackup.sh -U -S

    Da jetzt aber die Beta 0.6.7 verfuegbar ist musst Du einen etwas umstaendlicheren Weg waehlen:

    Code
    wget https://linux-tips-and-tricks.de/downloads/raspiBackup.sh/download -O raspiBackup.sh
    sudo mv /usr/local/bin/raspiBackup.sh /usr/local/bin/raspiBackup.sh.old
    sudo mv raspiBackup.sh /usr/local/bin/
    sudo chmod +x /usr/local/bin/raspiBackup.sh

    Allerdings schreibst Du dass Du die Option -l im umount gesehen hast. Die gibt es aber in dem alten Stand 6c10535 nicht :conf:

    Pruefe noch mal genau welche Version Du bei Dir nutzt. Wenn der Move der Logdatei nicht klappt sollte die Logdatei noch in /root stehen wenn Du raspiBackup per cron aufgerufen hast. In der siehst Du die Versionsinformationen in der ersten Logzeile.

  • Da jetzt aber die Beta 0.6.7 verfuegbar ist musst Du einen etwas umstaendlicheren Weg waehlen:

    Ist eine kleine Unschoenheit die ich eben in der Beta 0.6.7 gefixed habe :). Wenn dann die Beta nicht installiert wird kann man auch zukuenftig die aktuelle Release einfach auf den aktuellsten Stand bringen.

  • framp

    Oh, sorry. Ich hab' wohl was falsch gemacht :(

    Ich habe den Backup von der Konsole gestartet. Keine Log-Datei verfügbar. Inzwischen ist noch mehr kaputtgegangen und ich habe einen Restore durchgeführt (vorgestern) :)

    Code
    raspiBackup.sh --version
    Version: 0.6.6.1 CommitSHA: 6c10535 CommitDate: 2021-10-14 CommitTime: 12:28:41

    Für die aktuelle Version (nicht beta) bin ich jetzt etwas verunsichert. "wget" oder Standardverfahren?

  • Oh, sorry. Ich hab' wohl was falsch gemacht

    Darum gibt es die Versionsinfo damit ich sowas bemerke. Kommt öfter vor als Du denkst ... nicht nur Dir passiert sowas :shy:

    Das Standardverfahren funktioniert erst in der nächsten Version :) Du musst die 4 Befehle oben mit wget, zweimal mv und chmod ausführen um Deinen 0.6.6.1 Stand zu aktualisieren.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!