Re: Top, Userprozesse und Systemprozesse

[ternaryd <ternaryd@gmail.com>]

On Fri, 7 Jun 2019 00:05:32 +0200
Martin Reising <mreising+debian@nixhier.org>
wrote:

> 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.

Wie gesagt, das ist ein nfs root fs, sodaß die
NFS Optionen schon auf der Kommandozeile für
den Kernel stehen müssen. Diese lautet:

    [    0.000000] Kernel command line: \
    vme_tsi148.geoid=1 root=/dev/nfs \
    nfsroot=172.23.128.122:/srv/cnc,v3,tcp,noacl,nolock\
    nfsrootdebug rw keep_bootcon panic=1 \
    console=ttyS0,115200 \
ip=172.23.128.121:172.23.128.122:172.23.128.122:255.255.255.252:cnc:eth0:off

Scheinbar muß man "nfsvers=3" hier mit "v3"
schreiben.

Diese Tests habe ich immer parallel auf der
Maschine gemacht, bei der der Fehler nicht
auftritt, und einer wo schon. Die Maschine,
auf welcher der Fehler nicht auftritt (und alle
anderen vor dieser Änderung) hatten als
einzigen Unterschiede nicht "tcp,noacl,nolock"

Sicherheitshalber habe ich das Analoge auch in
/etc/fstab auf dem client und in /etc/exports
auf dem server gemacht:

client fstab:

    172.23.128.122:/srv/cnc / nfs \
    rw,nodev,exec,suid,auto,async,nfsvers=3,tcp,noacl,nolock\
    0 0
    172.23.128.122:/home/data /home/data nfs \
    rw,nodev,exec,suid,auto,async,nfsvers=3,tcp,noacl,nolock\
    0 0

server export:

    /srv/cnc \
    172.23.128.121/32(rw,no_root_squash,sync,no_subtree_check,fsid=0)
    /home/data \
172.23.128.121/32(rw,no_root_squash,sync,no_subtree_check,fsid=1,anonuid=1001,anongid=1001)

Leider tritt der Fehler immer noch auf. Gleich
nach dem boot kann ich sehen, daß die Maschine
mit dem Fehler eine in etwa 20% höhere Last
hat, wofür ich absolut keinen Grund finden
kann. Das ist aber noch nicht kritisch. Nach
etwa 24h dreht die CPU dann auf etwa 1.3 hoch,
was so eine Art Schwellwert ist; ab hier treten
Instabilitäten auf. Noch einmal 24 Stunden, und
die Last geht auf vielleicht 1.9, die Maschine
ist nun ständig instabil. Wenn ich es noch
länger lasse, geht es sehr langsam aber doch
weiter hoch; nach einer Woche kann ich dann
auch 2.5 sehen.

Was könnte ich noch probieren?

> Wenn die NFS-Optionen keine Verbesserung
> bringen, würde ich zusätzlich die Umstellung
> auf PtP wieder Rückgängig machen. Gefühlt
> ist PtP und NFS keine alltäglich Kombination
> und damit eine weitere mögliche Problemquelle.

Könntest du das hier ein wenig erläutern, denn
ich kann das nicht ganz nachvollziehen. Die
die Maschine, die immer funktioniert, hat genau
die gleiche Netzwerkkonfiguration. Alle anderen
Netzwerkoperationen scheinen ganz normal zu
funktionieren.

Danke!