Re: NFS client renders system unusable

[mlelstv%serpens.de@localhost (Michael van Elst)]

bsd-xen%roguewrt.org@localhost ("Sarton O'Brien") writes:

>The system at least now responds but nfs still eventually locks up:

># /etc/rc.d/mldonkey stop
>Stopping mldonkey.
>Waiting for PIDS: 904, 904, 904, 904, 904, 904, 904, 904, 904, 904, 904, 
[...]
>904, 904, 904, 904, 904, 904, 904, 904, 904, 904nfs server 
>192.168.15.8:/usr/local/svc/mldonkey: not responding
>, 904, 904, 904nfs server 192.168.15.8:/usr/local/svc/mldonkey: is alive 
>again
>, 904, 904, 904, 904, 904, 904, 904, 904, 904, 904, 904, 904, 904, 904, 
[...]

>And it's highly unlikely it will ever actually terminate without a -9.


If it does terminate with a -9 then there is no more NFS lockup but
probably a bug in the application.


>1006  904    1   0   2    2  24 19 7904 37920 parked   DW-  ttyp0   
>0:05.07 /usr/pkg/libexec/mldonkey/mlnet -pid /var/run/mldonkey
>1006  904    1   0   1    2  76 19 7904 37920 nfsrcv   DW   ttyp0   
>0:05.07 /usr/pkg/libexec/mldonkey/mlnet -pid /var/run/mldonkey
>   0 3640  377   0   1    1  85  0  748  1108 wait     DW   ttyp0   
>0:00.06 /bin/sh /etc/rc.d/mldonkey stop

All your processes seem to be swapped out? Seems to be srange.


>The problem seems to occur when more files are added to the list that is 
>maintained by mldonkey, which are subsequently managed over nfs by the 
>program. The program obviously wasn't designed for this use but do you 
>have any idea what I might need to do to accomodate it? I have increased 
>vfs.nfs.iothreads

iothreads should be scaled by number of CPUs available, the Solaris people
said "number of CPUs + number of active network interfaces + 1".

It is generally a bad idea to increase it.

-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."