XigmaNAS

Ich glaub ich hab sowas ähnliches, auch mit einem Linux Mint 18.1 Notebook. Gestern hab ich auch erhöhte CPU Last am NAS gemessen, nach Abschalten des Notebooks war diese wieder weg...
Hab mir jetzt erst Mal nichts weiter dabei gedacht, ich muss mal prüfen ob das auch bei mir reproduzierbar ist.

spy0r wrote: ↑

06 Jun 2017 13:23

...
Hab mir jetzt erst Mal nichts weiter dabei gedacht, ich muss mal prüfen ob das auch bei mir reproduzierbar ist.

Und da waren es schon zwei Wobei das bei mir bei einem Clienten schon auf 50% klettert. Deine harte Ware ist vielleicht potenter.
Schau dann auch mal unter Diagnose -> Informationen, Reiter "Netwerkstatus" und "Sockets".

Old-Papa

Hallo old-papa,

Könntest du mal bitte den Eintrag in deiner fstab hier posten? Sonst bleibt mir nur die Glaskugel...

Grüße
Princo

Princo wrote: ↑

06 Jun 2017 23:49

Hallo old-papa,
Könntest du mal bitte den Eintrag in deiner fstab hier posten? Sonst bleibt mir nur die Glaskugel...
Grüße
Princo

Bitte sehr... (ich dachte, ich hätte schon)


Da ist ja nichts Besonderes dran.
Mit exakt den gleichen Eintragungen (bei NAS) läuft der LM 17.2er Rechner nicht amok. Dort kann ich auch die smb-Freigabe (also nicht auskommentiert) benutzen.

Old-Papa

Hallo old-papa,

Du hast da einen Tippfehler drin:

Anstelle von ██████ muß es ██████ heißen.

Brüller

Spaß beiseite.

Eine Information wäre noch wichtig: Ist dein Notebook per Kabel, oder per WLAN ans Netz angeschlossen?

Grüße
Princo

Princo wrote: ↑

07 Jun 2017 02:43

Hallo old-papa,
Du hast da einen Tippfehler drin:
Anstelle von ██████ muß es ██████ heißen.
Brüller

Der Schenkelklopfer des Jahres!

Princo wrote: ↑

07 Jun 2017 02:43

Eine Information wäre noch wichtig: Ist dein Notebook per Kabel, oder per WLAN ans Netz angeschlossen?
Grüße
Princo

Wer Funk kennt, nimmt Kabel
Ist aber auch egal, dieses Verhalten ist via Kabel genauso reproduzierbar wie mit W-LAN.
Wer bitte bindet ein NAS mit W-Lan an. Ok, Handy und Tablet vielleicht, doch wenn ich gigabyteweise Daten schaufeln möchte, dann wäre W-LAN das letzte worauf ich setzen würde.

Old-Papa

Gibt es von der Linux Mint 18.1 Distri eine Live-CD ?
Wenn ja schonmal von der gebootet und die fstab angepasst ?

Ein sudo mount -a liest dann die fstab ein.

Mit welchem Ziel? Wir haben doch schon 2 unabhängige Systeme die das Verhalten zeigen.
Ich geh davon aus, dass der Dateimanager NEMO irgendwas versucht zu indizieren oder so...

@old-papa: Tritt das Phänomen bei dir immer auf oder nur wenn der Dateimanager geöffnet ist/war?

Ich werde bei Gelegenheit auch mal weiter forschen, auch wenn es mich bisher nicht weiter beunruhigt hatte

spy0r wrote: ↑

07 Jun 2017 15:35

Mit welchem Ziel? Wir haben doch schon 2 unabhängige Systeme die das Verhalten zeigen.
Ich geh davon aus, dass der Dateimanager NEMO irgendwas versucht zu indizieren oder so...

Kann sein.

spy0r wrote: ↑

07 Jun 2017 15:35

@old-papa: Tritt das Phänomen bei dir immer auf oder nur wenn der Dateimanager geöffnet ist/war?

Sobald ich gebootet und angemeldet bin. Lass ich die Kisten danach einfach in Ruhe, beginnt der Zirkus irgendwann.

spy0r wrote: ↑

07 Jun 2017 15:35

Ich werde bei Gelegenheit auch mal weiter forschen, auch wenn es mich bisher nicht weiter beunruhigt hatte

Ja, eine Katastrofe ist das nicht, aber es nervt, wenn da was ist, was nicht sein sollte

Old-Papa

Lösung:

In Services|CIFS/SMB|Settings bei "Auxiliary parameters" folgenden Wert eintragen:
Lösungsweg:

Ich habe den Eintrag von old-papa in der fstab bei mir nachgestellt (unter LinuxMint 18.1).
Nach ca. 16 Minuten trat der beschriebene Effekt auch bei mir auf.

Ich habe dann auf dem betreffenden Client-Rechner "top" aufgerufen. Dort wurde angezeigt, daß der Prozeß "cifsd" ungewöhnlich viel Prozessorzeit beansprucht. Das geschah immer dann, wenn auf dem NAS das ungewöhnliche Verhalten sichtbar wurde.

Eine Google-Suche mit "cifsd high cpu" führte dann zu dieser Beschreibung: https://bugzilla.kernel.org/show_bug.cgi?id=194531

Der Fehler liegt tatsächlich beim Linux-Rechner im Kernel, und irgendwann wird er dort mit Sicherheit beseitigt werden.

Dennoch ist es ratsam, den obigen Parameter auf dem NAS zu setzen, da es nicht sein darf, daß sich das NAS durch einen marodierenden Client beeinträchtigen läßt.

Der Fehler wurde übrigens auch schon im Forum behandelt: viewtopic.php?f=21&t=12380&p=77558&hili ... ime#p77558 (aber das ist nicht leicht zu finden gewesen).

Grüße
Princo

Wow, good job!
Ich hatte gestern offensichtlich nicht genug Geduld, meine CPU Last ging trotz meines Mint Notebooks nicht hoch, ich werde aber den Parameter hinzufügen.
Kannst du der vollständigkeit halber noch kurz beschreiben, was der Parameter genau macht?

Danke & Gruß,
Stef

Edit: Menschen sind einfach so faul... Musst du natürlich nicht, das kann ich auch selber:

deadtime
This global option sets the number of minutes that Samba will wait for an inactive client before closing its session with the Samba server. A client is considered inactive when it has no open files and no data is being sent from it. The default value for this option is 0, which means that Samba never closes any connection, regardless of how long they have been inactive.

Quelle: https://www.samba.org/samba/docs/using_samba/ch11.html

Herzlichen Dank!
Sobald ich zuhause bin werde ich das mal fixen. Ich dachte schon, als Linuxneuling habe ich was verbockt.

Gruß
Old-Papa

Update:



Hier nun das Ergebnis. Das sieht im ersten Diagramm zwar noch heftig aus, doch vorne sieht man, es sind nur wenige Prozent.
Im unteren Diagramm dann mal die Wochenübersicht. Die teils heftigen Ausschläge beruhten alle auf der LM 18-1-Macke.

Old-Papa

Hier noch die Übersetzung zu Deadtime....

Todeszeit
Diese globale Option legt die Anzahl der Minuten fest, die Samba auf einen inaktiven Client wartet, bevor er seine Sitzung mit dem Samba-Server schließt. Ein Client wird als inaktiv betrachtet, wenn er keine offenen Dateien hat und keine Daten von ihm gesendet werden. Der Standardwert für diese Option ist 0, was bedeutet, dass Samba niemals eine Verbindung schließt, unabhängig davon, wie lange sie inaktiv waren.

So, ich war jetzt wieder so verwegen, dass im Startpost auf "gelöst" zu setzen.
Ich habe gestern noch ein aktuelles Update zu LM 18.1 eingespielt dabei auch ein neuerer Kernel. Dann testweise im NAS die "deadtime =0 rausgenommen, das Gerödel fing wieder an. Die Macke ist also auch in diesem Kernel noch nicht behoben.
Dann hatte ich gestern noch auf einem anderen LM 18.1er Rechner (ohne Kernelupdate) erneut das Gerödel, allerdings hatte ich das NAS kurzzeitig ausgeschaltet (der LM 18.1er Rechner blieb an). Als das NAS wieder gebootet war fing das irgendwann an. Ich konnte auch nicht via SMB auf das NAS zugreifen. Reboot von LM 18.1 und gut war. Wenn also eine gemountete Freigabe hart abgerissen wird verschluckt sich die Kiste wohl. Ok, dass würde ich auch verstehen

Old-Papa