[Linux-cluster] lock_gulm is very slow. why ?

[Levent Serinol]

here is the result with ignore_local_fs option:

Time:
        81 seconds total
        6 seconds of transactions (166 per second)

Files:
        10692 created (132 per second)
                Creation alone: 10000 files (434 per second)
                Mixed with transactions: 692 files (115 per second)
        899 read (149 per second)
        101 appended (16 per second)
        10692 deleted (132 per second)
                Deletion alone: 10384 files (199 per second)
                Mixed with transactions: 308 files (51 per second)

Data:
        21.05 megabytes read (266.07 kilobytes per second)
        250.41 megabytes written (3.09 megabytes per second)







On Thu, 22 Jul 2004 09:58:37 -0500, Ken Preslan <kpreslan at redhat.com> wrote:
> On Thu, Jul 22, 2004 at 09:53:45AM -0500, Michael Conrad Tadpol Tilstra wrote:
> > On Thu, Jul 22, 2004 at 12:53:48PM +0300, Levent Serinol wrote:
> > > Hi,
> > >  I have done some benchmark tests with postmark(tests repeated many
> > > times). There is one client (also it is lock server). and another one
> > > which exports it's scsi hard disk with gnbd.
> > [snipped a lot of nice data]
> > > as you can see nolock results is 2 times (some parts 3 times) faster
> > > then with locked one .
> > > what could be the problem ? is there any workaround or settune option
> > > (releasing locks earlier,etc...) ?
> >
> > the biggest thing you are probably running into is that when running
> > with lock_nolock, gfs knows that it is not in a cluster, therefor it can
> > enable some optimisations that only work for lcoal filesystems.  These
> > optimisations would corrupt disk data if you had multiple nodes mounted.
> 
> You can turn off those optimizations with lock_nolock by mounting with
> "-o ignore_local_fs".  That will let us figure out what is optimizations
> and what is lock latency.
> 
> > There is also no network traffic for handling lock in lock_nolock, but
> > that is minor compaired to the local file system optimisations.
> >
> > Basically, gfs with lock_nolock should always be quite faster than with
> > any cluster locking (lock_gulm or lock_dlm).
> >
> > Ken could say more on this.
> >
> > --
> > Michael Conrad Tadpol Tilstra
> > Reality is for people who lack imagination.
> 
> 
> > --
> > Linux-cluster mailing list
> > Linux-cluster at redhat.com
> > http://www.redhat.com/mailman/listinfo/linux-cluster
> 
> --
> Ken Preslan <kpreslan at redhat.com>
> 
> --
> Linux-cluster mailing list
> Linux-cluster at redhat.com
> http://www.redhat.com/mailman/listinfo/linux-cluster
> 


-- 
--

Stay out of the road, if you want to grow old. 
~ Pink Floyd ~.