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

RE: [Linux-cluster] GFS performance

Well, in our applications usage we don't keep cycling over the same files over and over again, we run through lots of files and keep a handful open at any point in time, so perhaps shorter demote_secs is good for us.

I have not been able to find out about 'gfs_controld -l0' -- where is that set and what does "-l0" do?

- K

-----Original Message-----
From: linux-cluster-bounces redhat com [mailto:linux-cluster-bounces redhat com] On Behalf Of Ferenc Wagner
Sent: Friday, January 04, 2008 10:35 AM
To: linux clustering
Subject: Re: [Linux-cluster] GFS performance

Kamal Jain <kjain aurarianetworks com> writes:

> On the demote_secs tuning parameter, I see you're suggesting 600
> seconds, which appears to be longer than the default 300 seconds as
> stated by Wendy Cheng at
> http://people.redhat.com/wcheng/Patches/GFS/readme.gfs_glock_trimming.R4
> -- we're running RHEL4.5.  Wouldn't a SHORTER demote period be
> better for lots of files, whereas perhaps a longer demote period
> might be more efficient for a smaller number of files being locked
> for long periods of time?

It depends on your usage pattern.  I had to access lots of files
repeatedly, ie. cycling over them periodically by one machine in the
cluster.  It helped me a LOT to keep those GFS locks cached on that
machine, while the others were all right without being lock masters as
they ever needed some of the files only, not all of them.

> On a related note, I converted a couple of the clusters in our lab
> from GULM to DLM and while performance is not necessarily noticeably
> improved (though more detailed testing was done after the
> conversion), we did notice that both clusters became more stable in
> the DLM configuration.

I've never tried GULM, so I can't comment on this.

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