SMB Dienst läuft Amok - hohe CPU

  • Seit 2 Monaten habe ich Punkt einer genauen Uhrzeit eine hohe CPU Last und das 2h lang. Auch wenn andere PCs aus sind. Auch ist kein cronjob auf der NAS für diese Uhrzeit zu sehen auch sonst wüßte ich nichts, was da läuft. Die Sicherung auf die externe USB-HDD ist morgens und das sicher ohne smb.


    Der SMB Dienste scheint irgendwie 2h mit sich selbst beschäftigt zu sein.


    Wie bekomme ich genau heraus, was Samba da treibt? Die Logs per Browser geben nichts her. tcpdump ist nicht installiert ... Ich denke es ist irgendetwas lokales. Kenne ich von Samba eigentlich so nicht. Habe an der Konfig und am Netzwerk ~eigentlich~ auch nichts geändert.


    Plattenzuwachs bei hoher Samba-CPU Last ist auch nicht zu beobachten - daß ggf ein Netzwerkgerät da etwas drauf schreiben will.


    Grüße
    Michael

  • Da wird irgendwas im Hintergrund arbeiten. Wann genau ist die CPU-Last? Immer zur gleichen Zeit? Jeden Tag oder wöchentlich?
    Wie sieht es aus mit:
    - Virenscan
    - RAID Scrubbing
    - Indexierung von Qsirch, Photostation etc.


    Kannst Du das Systemprotokoll posten.


    Welche Dienste und Apps sind aktiv?


    Welche Firmware?

  • >Wann genau ist die CPU-Last?
    14:00 - 17:30


    >Immer zur gleichen Zeit?
    Ja.


    >Jeden Tag oder wöchentlich?
    jeden Tag


    >Wie sieht es aus mit:
    >Virenscan
    Nein - deaktiviert. Client Virenscan kann auch nicht sein, weil ist auch, wenn Clients vom Netz.


    >RAID Scrubbing
    Hat wohl wenig mit dem smbd Dienst zu tun. Platten sind ok.


    >Indexierung von Qsirch, Photostation etc.
    Nein.


    >Kannst Du das Systemprotokoll posten.
    Das gibt nichts her.


    >Welche Dienste und Apps sind aktiv?
    Das Übliche - eher wenige als mehr. Wie gesagt, mit selber Config lief die schon Jahre normal.


    >Welche Firmware?
    4.2.6 die vom 2017/09/05


    Ich bräuchte paar tipps und Linux Befehle um zu wissen, was der smbd Dienst da tut.


    Angefangen hat das in KW31

  • Ich bräuchte paar tipps und Linux Befehle um zu wissen, was der smbd Dienst da tut.

    Du kannst sehr low-level einen Trace der System-Calls erzeugen. Wieviel man daraus lesen kann, wird man dann sehen.
    Dafür musst du über Entware-ng das Paket strace installieren. Danach suchst du mit ps | grep smbd nach dem Prozess und dessen PID. Da mehrere Instanzen des Dienstes laufen werden, verwende den mit der höchsten CPU-Last hat. Das kannst du in der Shell auch per top rausfinden (ist vermutlich die gleiche Prozessliste, die auch der Resourcenmonitor anzeigt).


    Dann mit strace -p PID -o /share/Public/strace_smbd.log an den Prozess anhängen und etwas laufen lassen, danach per Ctrl+C abbrechen.
    Die Datei kannst du dann mit einem Texteditor anschauen. Idealerweise wirst du Dateinamen oder Verzeichnisnamen drin finden (auch Systemdateien), ansonsten wird es schwer.

    Angefangen hat das in KW31

    Was hast du da geändert? QTS-Upgrade oder eine App installiert? Oder eine Netzwerkänderung?

  • Der Inhalt der strace...log bringt mich nicht wirklich weiter. Anbei ein Ausschnitt und die Muster wiederholen sich. Der Amok-smbd Prozeß lief erst unter admin und dann unter meinem Benutzer xyz mit selber PID. xyz ist auf der NAS als Benutzer angelegt. via tcpdump sehe ich keinen großen Netzwerk-Verkehr. Die Kiste scheint eher mit sich selbst beschäftigt.



  • Gibt es irgendwelche Netzwerkgeräte die das Problem auslösen könnten? Smart TV, TV-Boxen, Streaming Clients, IoT-Geräte, Drucker, Netzwerk-Scanner, Spielkonsolen, Router, Firewall etc.
    Zum Testen die QNAP einmal komplett vom Netzwerk trennen und einmal direkt mit nur einem PC verbinden und prüfen ob zu dieser Zeit wieder das selbe Verhalten ist.

  • 3 echte PCs waren schon offline. Sonst gibt es nur die Fritzbox, 2 IP Tel, 2 Raspi. Wie gesagt, per tcpdump gibt es da keinen traffic. Blöd, daß man da bei Samba scheinbar keinerlei Analyse-möglichkeiten hat. Kann man aus dem trace irgendetwas erkennen?


    Wenn ich Zeit habe, trenne ich wirklich mal die NAS vom Netz ab.

  • Es muss ja nicht zwingend Traffic sein, der den Samba-Dienst beschäftigt. Irgendwelche kurzen aber falschen oder inkompatiblen Befehle reichen hier auch.


    Mit Samba-Analyse kenne ich mich leider nicht aus. Das Log oben sagt mir nicht all zu viel.

  • Ich würde mal sagen, irgendwas scannt über Samba die Freigaben. Das kann durchaus auch über localhost gehen und ob man das per tcpdump sieht? Läuft evtl. lokal eine Anwendung, die über Samba zugreift? Evtl. ein Cronjob?


    Achja, was war denn nun in KW31?

  • Oh - peinlich - mea culpa. Kaum war die vm mit w7 aus - schon war heile Welt. Im Taskplaner war von Treesize noch ein Task hinterlegt, der eine tägliche Statistik der Freigaben erstellt.


    Aber: Dieser Task wurde am 12.4. erstellt und zu dem Zeitpunkt lief laut der Auswertung alles normal. Es kamen auch nicht wirklich neue Dateien dazu, daß treesize hätte mehr scannen müssen - bzw war der scan von treesize nie ein CPU Problem. Windows-Updates gab es für w7 zu dem Zeitpunkt/wurden eingespielt nicht. Ich meine auch kein Firmwareupdate der NAS.


    Ähnliches gab es mal mit robocopy, da stieg die NAS CPU bei einer Sicherung auch hoch - dafür gab es einen Hotfix für Windows 7. Ggf geht es in die Richtung. Jedenfalls ist die primäre Ursache gefunden. merci.