Update on the use case: The main headache for our developers is the intellisense feature in the graphical ide which suffers from the performance problem. Peter ~ On Wed, Aug 11, 2010 at 2:35 PM, Jeff Sturm <jeff.sturm@xxxxxxxxxx> wrote: >> -----Original Message----- >> From: linux-cluster-bounces@xxxxxxxxxx > [mailto:linux-cluster-bounces@xxxxxxxxxx] >> On Behalf Of Peter Schobel >> Sent: Wednesday, August 11, 2010 3:28 PM >> To: linux clustering >> Subject: Re: How does caching work in GFS1? >> >> Increasing demote_secs did not seem to have an appreciable effect. > > We run some hosts with demote_secs=86400, for what it's worth. They > tend to go through a "cold start" each morning, but are responsive for > the remainder of the day. > >> The du command is a simplification of the use case. Our developers run >> scripts which make tags in source code directories which require >> stat'ing the files. > > Gotcha. I don't have many good suggestions for version control, but I > can offer commiseration. Some systems are worse than others. > (Subversion for instance tends to create lots of little lock files, and > performs very poorly on just about every filesystem we've tried.) > > How much RAM do you have? All filesystems like plenty of cache. > > One thing you can do is run "gfs_tool counters <mount-point>" a few > times during your 20GB test, that may give you some insight. For > example, does the number of locks increase steadily or does it plateau? > Does it abruptly drop following the test? Does the "glocks reclaimed" > number accumulate rapidly? When locks are held, stat() operations tend > to be very fast. When a lock has to be obtained, that's when they are > slow. > > (Any cluster engineers out there, feel free to tell me if any of this is > right or wrong--I've had to base my understanding of GFS on a lot of > experimentation and empirical evidence, not on a deep understanding of > the software.) > > -Jeff > > > > -- > Linux-cluster mailing list > Linux-cluster@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/linux-cluster > -- Peter Schobel ~ -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
