[Linux-cluster] GFS: more simple performance numbers

David Teigland teigland at redhat.com
Wed Oct 20 04:16:59 UTC 2004


On Tue, Oct 19, 2004 at 01:05:54PM -0500, Derek Anderson wrote:
> I've rerun the simple performance tests originally run by Daniel McNeil with 
> the addition of the gulm lock manager on the 2.6.8.1 kernel and GFS 6.0 on 
> the 2.4.21-20.EL kernel.

Understanding the different results from the following five tests might be
helpful in understanding the others.  In all these tests, there is just
one node doing the same tar.

1. ext3 tar

2. gfs-nolock tar

3. gfs-dlm 1 node tar (where this is the only node with gfs mounted)

4. gfs-dlm 1 node tar (where two nodes have gfs mounted)

5. gfs-gulm 1 node tar (where a lock server is running on another node)


A start on some of the observations I expect we'll make:

- The results of 2 and 3 are about the same.

  This should illustrate that there is some performance loss when
  comparing gfs to a local fs that /isn't/ due to locking.  (e.g.
  effects of distributed metadata.)

- The result of 4 is significantly longer than 3.

  In case 4, about half of the resource directory lookups are remote
  operations.  In case 3 they are all local.  The point is that we
  need to be aware of which "1 node tar" number we use for comparison.

Understanding these (and maybe other) "structural" effects will help us
identify the fixable performance bugs.  Historically, many no-contention
tests on gfs (like tar in different directories) have scaled nearly
linearly.  I suspect the dlm is to blame to the extent that's not true at
the moment.  It's something we're beginning to look into thanks to the
posted test results.

-- 
Dave Teigland  <teigland at redhat.com>




More information about the Linux-cluster mailing list