Hi, On Fri, 2010-08-20 at 09:34 -0700, Peter Schobel wrote: > 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 Just a hunch but does that use i/dnotify or something along those lines? That is common in GUIs and not supported on gfs/gfs2, although the chances are that it will work for local fs modificatons only, Steve. > ~ > > 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 > > > > > -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
