Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Rushmed]

Hallo,

auf meinem PI4 nutze ich schon lange neben dem ioBroker, Grafana und InfluxDB auch Samba Freigaben für ein kleines NAS.
Bis her lief alles tipptopp. Nun habe ich seit etwa einer Woche extrem hohe CPU Auslastung beim Übertragen großer Dateien (30 GB).
Htop sieht wenn ich gerade keine Datei per SMB übertrage etwa so aus:

und bei Dateiübertragung so:

Die Datenübertragung schlägt dann fehl und das System ist merklich überlastet.

Ich hatte natürlich zuerst die HDD im Verdacht und mir gleich eine andere geholt mit dem selben Verhalten.
Dann habe ich meinen Testraspi neu aufgesetzt und nur ioBroker und SMB installiert. Das geht ein klitzekleines Bisschen besser. Mit gestopptem ioBroker lief die Übertragung sehr mühsam durch.

Bevor dieses Verhalten vor, wie gesagt etwa einer Woche, zu ersten Mal auftrat hatte ich nie irgendwelche Probleme bei voll laufendem System auch noch große Dateien zu übertragen.

Hat jemand eine Ahnung was da los sein kann?

[BananaJoe]

@rushmed Wenn es bei der Übertragung zur/von der HDD zu Problemen/Wartezeiten/Latenzen kommt kann das auch eine hohe CPU Last erzeugen. Der Prozess der auf den Lese- oder Schreibvorgang wartet erzeugt in dem Moment viel CPU.

HDD oder SSD? Was ist mit dem USB-Adapter mit dem die Festplatte angeschlossen ist? Liest oder Schreibst du?
System selbst auf SD-Karte? Was steht im SYSLOG bzw. kommen da Einträge während du kopierst?

[Rushmed]

@bananajoe HDD
Worauf bezieht sich die Frage mit dem USB Adapter, das ist der selbe wie vor eine Woche.
Meine Schilderungen im ersten Post bezogen sich aufs auf der HDD am Raspi Schreiben. Hab gerade ebenso erfolglos Lesen getestet.

Im SYSLOG erscheinen während des Lesens diese SMB Einträge:

Aug  5 21:55:56 Smartazamba smbd[15643]: [2021/08/05 21:55:56.875205,  0] ../source3/param/loadparm.c:3669(load_usershare_shares)
Aug  5 21:55:56 Smartazamba smbd[15643]:   load_usershare_shares: directory /var/lib/samba/usershares is not owned by root or does not have the sticky bit 't' set or is writable by anyone.
Aug  5 21:55:56 Smartazamba smbd[15643]: [2021/08/05 21:55:56.881067,  0] ../source3/param/loadparm.c:3669(load_usershare_shares)
Aug  5 21:55:56 Smartazamba smbd[15643]:   load_usershare_shares: directory /var/lib/samba/usershares is not owned by root or does not have the sticky bit 't' set or is writable by anyone.

Aug  5 21:58:29 Smartazamba smbd[15643]: [2021/08/05 21:58:29.443861,  0] ../source3/param/loadparm.c:3669(load_usershare_shares)
Aug  5 21:58:29 Smartazamba smbd[15643]:   load_usershare_shares: directory /var/lib/samba/usershares is not owned by root or does not have the sticky bit 't' set or is writable by anyone.

Das System selbst auf einer SSD.

[Thomas Braun]

@rushmed sagte in PI4 Samba smb hohe CPU last:

/var/lib/samba/usershares

Und wie sehen die Rechte da nun genau aus?

ls -l /var/lib/samba/usershares

[BananaJoe]

@rushmed sagte in PI4 Samba smb hohe CPU last:

@bananajoe HDD
Worauf bezieht sich die Frage mit dem USB Adapter, das ist der selbe wie vor eine Woche.

Und kann also noch genauso defekt / die Ursache sein.

Mhh, wenn er noch was anderes macht könnte das auch behindern, also wenn er auf der SSD am rödeln ist behindert das auch den HDD Verkehr. Am Pi teilen sich die Geräte ja den USB-Bus. Und ich meine die Netzwerkkarte hängt am gleichen USB-Bus. USB 3.0 soll bis zu 5GBit/s schaffen, das wären theoretisch 596Mbyte/s
Laut Internet sind beim lesen über 200Mbyte und beim schreiben über 100Mybte/s am Pi möglich ... ohne Netzwerk.

Wenn ich so google sehe ich das viele aber beim NAS Einsatz nicht über 20-30Mbyte/s kommen.
Da wird der USB-Bus bremsen. Und das der Pi dafür nicht gebaut ist.
Bei SAMBA muss der ja den SMB-Datenverkehr noch in Linux-Dateisystem-Datenverkehr übersetzen und umgekehrt.
Man bräuchte Vergleichswerte wie es bei der Geschwindigkeit und der CPU Last aussieht.

Bei kleine Dateien kann der das aus dem Cache erledigen, bei 30GByte sind die Caches (Schreib und Lese) voll, das geht es dann auf die wirkliche Performance die das Teil ganz unten drunter schafft runter: CPU, USB und die HDD

Und wenn ich den Screenshot deute so vermute ich das es der SAMBA-Prozess ist. Der auch hohe CPU haben wird wenn er mit den Umwandeln nicht hinterher kommt. Aber auch wenn er die Daten nicht los wird oder nicht bekommt (also Festplatte und Netzwerk).

Ja ich dreh mich im Kreis, aber so ist es nunmal.

[Rushmed]

@thomas-braun sagte in PI4 Samba smb hohe CPU last:

@rushmed sagte in PI4 Samba smb hohe CPU last:

/var/lib/samba/usershares

Und wie sehen die Rechte da nun genau aus?

ls -l /var/lib/samba/usershares

pi@Smartazamba:~ $ ls -l /var/lib/samba/usershares
insgesamt 0

Ich hab gerade ein altes Systembackup auf einer anderen SSD mit anderem USB Adapter wiederhergestellt. Das sieht bisher gut aus, ich teste das jetzt noch.

Folgende Beobachtungen bisher:

• das alte Backup funktioniert auch nach:

sudo apt update && sudo apt dist-upgrade

Ich hatte vermutet dass die Änderung durch ein Update kam.

• SSD mit altem Backup an dem SSD Adapter den ich eingangs benutzt habe funktioniert auch
• beide SSDs mit dem aktuellen System zeigen wieder das beschriebene Problem

Ich habe auch festgestellt dass das ioBroker Webinterface mit dem Backup deutlich flotter beim Laden der Seiten ist.