(Illustration by Gaich Muramatsu)
On Fri, May 02, 2003 at 12:26:57AM -0700, Steve Simitzis wrote: > On 05/01/03, Jan Harkes <jaharkes_at_cs.cmu.edu> wrote: > > I'm not sure how easy it is to change this. There definitely isn't a > > command line or venus.conf option, so it would require a recompile. > > so then, does it help me to run maxclients at 100, or is that excessive? > i'm unsure how to best tune that number. is there a tool for observing > what venus is doing with its clients? Well, maybe we should really tie the number of rpc2 connected per user to a percentage of the number of worker threads. Something like 50%+1 (to make sure that it works even with a single worker thread). > > The thing that is interesting in your log is that all objects have a > > 'writer'. What kind of updatedb or slocate is running on your system? > > It might be opening all the files O_RDWR, which triggers venus to write > > back all the files after fetching. > > that's a good question. i'm running slocate 2.6, that came standard > with the redhat install this machine is based on. i added /coda to I just looked at the slocate 2.7 source and it only opens things O_RDONLY. Maybe I'm misinterpreting the writers bit, perhaps anyone who is fetching a files into the cache is a 'writer' because it is mutating cache state... Have to check that out some time. > updatedb.conf, so perhaps that will help matters. it seems that > updatedb starts in cron at 4:02am, which matches the 4:03am where the > log spew begins. I saw 04:0 something and immediately thought 'updatedb run'. It is a pretty decent exercise for Coda's cache replacement code. And clearly there are several problems still hiding there somewhere. JanReceived on 2003-05-02 11:36:49