On Fri, 20 Nov 2009, Alec T. Habig wrote:
Hi folks,
When users are running nautilus on a machine where their directories are
nfs-mounted, nautilus spends a substantial fraction of the client
machine's CPU, ~1.5Mbps of bandwidth, and a large load on the server's
nfsd I/O wait states. It looks like it is constantly stat'ing all the
files it can, although I haven't confirmed that with strace.
Initially the problem was with the gamin daemon doing the same thing,
but one can ask it not to do so by adding
fsset nfs none
to /etc/gamin/gaminrc
and it behaves. The problem then moves to nautilus itself, which acts
as if it's not satisfied with the gamin's lack of up-to-the-second
response and tries to do it itself.
Anyone know of a way to configure nautilus to behave? The alternative
is to annoy my users by making them all switch to kde instead, but
that's better than letting gnome DOS my nfs server.
thanks,
Alec
PS - SL5.4, although it also happened (with less dire consequences) in
SL5.3.
I've not yet tested things properly on sl54 but for sl53 we tweaked the
gamin config to tell it to poll the nfs servers less agressivly, and to
hack a couple of other paths which gamin was being confused about (somehow
it was convinced that they supported inotify but they don't)...
$ cat /etc/gamin/gaminrc
# $Id: gaminrc,v 1.2 2009/01/22 00:37:56 jp107 Exp $
#
# Teach gamin to poll these paths since in DAMTP they are symlinks to
# NFS but it thinks they can be checked with inotify - and they can't!
poll /var/spool/mail/* /var/mail/* 30
#
# This should be enough to set the poll interval for 'nfs' type
# file-systems - otherwise it defaults to polling every 10 seconds...
#fsset nfs poll 30
fsset nfs poll 20
in sl53 nautilus was only causing gamin to poll a few bits of the home
directory (e.g. ~/Desktop/) every 10 seconds so it wasn't a really _big_
problem.
I'm guessing that if gamin is told it can't monitor NFS then nautilus may
do some polling itself...
-- Jon
