[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Linux-cluster] How does caching work in GFS1?



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 eprize com> wrote:
>> -----Original Message-----
>> From: linux-cluster-bounces redhat com
> [mailto:linux-cluster-bounces redhat com]
>> On Behalf Of Peter Schobel
>> Sent: Wednesday, August 11, 2010 3:28 PM
>> To: linux clustering
>> Subject: Re: [Linux-cluster] 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 redhat com
> https://www.redhat.com/mailman/listinfo/linux-cluster
>



-- 
Peter Schobel
~


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]