<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:lhecking@users.sourceforge.net">lhecking@users.sourceforge.net</a> wrote:
<blockquote
cite="mid:20090910125634.422BF10DEF@cork.irdesign.cypress.com"
type="cite">
<blockquote type="cite">
<pre wrap="">Do you have anything running that would try to read all the files and build a
search index - like beagle? There's also the nightly run of updatedb but that
just reads the filenames and normally nfs mounts are excluded.
</pre>
</blockquote>
<pre wrap=""><!---->
There is no package beagle installed, I don't know if any other software
doing this is part of a standard CentOS install. Definitely not updatedb,
mlocate.cron runs once a day in the early morning, but the load pattern
we see is a continuous increase.
</pre>
</blockquote>
We had a similar issue with 100 CentOS 5 and Fedora 7 desktops mounting
their $HOME directories from a Centos 4 server. We would see a steady
(perfectly linear) increase of getattr and lookup requests from the
time users logged in until they shutoff their machines (logging off
stopped the linear growth but didn't always bring the number of
requests down). Running hundreds of dstats and straces finally showed
that the gamin package on each of the clients was causing all of the
requests and simply killing that single process would instantly drop
the getattr requests from 200 a second down to 3 or 4 a second where it
should be. That was 200 per client so you can imagine how bad it would
get! We rebuilt the gamin-0.1.9-5.rpm package and deployed it to all of
the machines. We instantly saw improvement and we currently average 3
getattr requests a second. I don't know if this will help your
situation but maybe someone will benefit.<br>
<br>
Chris<br>
</body>
</html>