Re: Top, Userprozesse und Systemprozesse
On Fri, 7 Jun 2019 00:05:32 +0200
Martin Reising <mreising+debian@nixhier.org>
wrote:
> Meine Erfahrung mit NFSv4 war das es für
> Programme wie libreoffice weniger Probleme
> gab, allerdings war es für $HOME mit den
> üblichen DE (Gnome, KDE und Unity)
> ohne .cache, .local/share/Trash, [...]
Ich habe auf dem kritischen Board nur eine
Datei mit Logausgaben die geschrieben werden.
Auf dem Rechner mit Festplatte sind zwei
Prozesse, die zwei weitere Dateien ins gleiche
Verzeichnis geschrieben hatten. Es hat
geholfen, das in ein anderes Verzeichnis
um zu lenken. Gelesen wird das fast nie, nur
bei der Fehlersuche, und da nur einmal, weil
ich mir die Logs dann auf einen schnelleren
Rechner kopiere. Die Menge kann ich über Filter
einstellen. Wenn ich's übertreiben will kann
ich auf ein paar Giga pro Stunde kommen, im
Normalfall sind es vielleicht ein paar hundert
Mega in 6 Monaten. Das kommt dann zeitlich
ziemlich konstant.
Ist das eine eher günstige oder ungünstige
Konstellation?
> Mit NFSv3 (hard,tcp) war das Ganze wieder
> brauchbar.
Ich weiß jetzt nicht auswendig, welche Optionen
ich gesetzt habe. Werde das morgen prüfen und
bei Unterschieden definitiv Tests machen. Was
mich halt ärgert ist, daß ich eine Maschine
habe, die das problemlos macht, und alle
anderen nicht. Die Zeilen in /etc/export
bzw. /etc/fstab sind aber identisch (und die
Kernel Kommandozeile vom Client).
> munin zeigt bei NFS Server ca. 21
> verschiedene Funktion und bei NFSv4 Server
> ca. 37 verschiedene Funktionen.
Mir ist eigentlich keine übermäßige Netzwerk
Aktivität aufgefallen; Steuerungsbefehle kommen
über UDP, und da gab es eigentlich nie
merkliche Verzögerungen. So frage ich mich
eher, welcher dieser Funktionen nun eine
Operation auslösen, die auf Client-Seite die
CPU in die Wolken dreht. Werde morgen ein wenig
mit munin spielen.
> Ich würde auf den NFS-Clients mal testweise
> die Optionen nfsvers=3,tcp,noacl,nolock
> verwenden um NFSv4-, ACL- und Lock-Probleme
> aus zu schließen.
Ich werde das vergleichen. Da aber der client
über NFS bootet, steht dies in der
Kommandozeile für den Kernel; nur das zweite
Verzeichnis ist dann auf /etc/fstab
> Wenn die NFS-Optionen keine Verbesserung
> bringen, würde ich zusätzlich die Umstellung
> auf PtP wieder Rückgängig machen.
Das ist nicht ganz trivial, denn ich muß diese
einzige Verbindung als Netzwerk isolieren,
damit von einem lokalen Netzwerk, welches
potentiell eine ähnliche Maske hat, keine
Querschläger dazwischen kommen können. Und eine
Firewall würde ich auf solchen Maschinen
vermeiden wollen. Schließlich hängt niemand
Werkzeugmaschinen ins Internet.
> Gefühlt ist PtP und NFS keine alltäglich
> Kombination und damit eine weitere mögliche
> Problemquelle
Hm. Ganz kann ich das nicht nachvollziehen.
Wenn ein Ping durchgeht, wenn ich ssh per TCP
problemlos machen kann, und wenn die Steuerung
mit UDP auch keinerlei Probleme macht, was
könnte NFS wollen, das ihm dabei fehlt und
dadurch dazu führt, daß die CPU Last hoch
fährt? Ich hätte erwartet, daß NFS sich um die
Netzwerkkonfiguration gar nicht kümmert. Das
schickt Pakete ab und hofft auf deren Ankunft.
Wie ist das bei NFS anders als bei anderen?
Was ich mich hier aber frage ist zweierlei:
Warum kann ich den Unterschied zwischen der
funktionierenden Maschine und den anderen nicht
finden, und ob das wirklich mit Netzwerk zu tun
hat, oder doch nur irgendwie mit dem Kernel
(und wenn dem so wäre, wie).
Reply to: