Am Sun, 27 Jun 2010 19:04:36 +0200
schrieb David Haller
Am Son, 27 Jun 2010, Al Bogner schrieb:
schrieb David Haller
: Überwachst du die Platten des NFS mit smartd? [SMART Attribute] Ich sehe da nichts auffälliges.
Ich auch nicht.
Ansonsten könntest du mal nen anderen io-scheduler verwenden bzw. an den NFS-Parametern drehen. Welchen Kernel verwendest du (-desktop, -default)?
Client 11.2 mit 2.6.31.12-0.2-desktop Server 11.1 mit 2.6.27.45-0.1-default
Zeig mal (v.a. vom Server) die Ausgaben von:
for f in /sys/block/sd*; do printf "%4s: ", "${f##*\/}"; cat "/sys/block/${f##*\/}/queue/scheduler"; done
Die NFS-Verzeichnisse sind alle xfs mit Standardoptionen. Server sda: ,noop anticipatory deadline [cfq] sdb: ,noop anticipatory deadline [cfq] sdc: ,noop anticipatory deadline [cfq] sdd: ,noop anticipatory deadline [cfq] Client sda: ,noop anticipatory deadline [cfq] sdb: ,noop anticipatory deadline [cfq]
Sobald am NFS-Server HD-Aktivität lös ist, bricht kurzfristig alles zusammen. Ähnliches Verhalten hatte ich aber unter Kmail auch schon und wurde lokal gespeichert.
und
awk '$3 ~ /nfs/ { print $4; }' /proc/mounts
Server awk '$3 ~ /nfs/ { print $4; }' /proc/mounts rw Client awk '$3 ~ /nfs/ { print $4; }' /proc/mounts rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.2.100,mountvers=3,mountproto=udp,addr=192.168.2.100 rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.2.100,mountvers=3,mountproto=udp,addr=192.168.2.100 rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.2.100,mountvers=3,mountproto=udp,addr=192.168.2.100 rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.2.100,mountvers=3,mountproto=udp,addr=192.168.2.100 rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.2.100,mountvers=3,mountproto=udp,addr=192.168.2.100 rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.2.100,mountvers=3,mountproto=udp,addr=192.168.2.100 rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.2.100,mountvers=3,mountproto=udp,addr=192.168.2.100 rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.2.100,mountvers=3,mountproto=udp,addr=192.168.2.100 rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.2.100,mountvers=3,mountproto=udp,addr=192.168.2.100 rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.2.100,mountvers=3,mountproto=udp,addr=192.168.2.100
Ich kenn das Phänomen auch manchmal, da braucht das Anlegen von nem Verzeichnis (auf nem fast vollen FS) mal 10s oder so ... Scheduler ist "anticipatory", -default Kernel. Muß nochmal die anderen scheduler testen.
Ich denke seidem ich clawa-mail auf das NFS-Verzeichnis schreiben lasse, wird die Sache erst auffällig. Bei einem Skript, dass sowieso Minuten bis Stunden dauert, fällt es nicht auf, wenn da mal 10Sekunden nichts passiert. Bei mvkmerge ist mir das heute aufgefallen, dass da nichts weiter geht. Wie könnte man testen, ob es an NFS oder direkt am Server liegt? Wie prüfe ich, ob es am Netzwerkkabel liegt? Al -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org