[Linux-cluster] GFS 6.0 Questions

[Gerald G. Gilyeat]

<snip>

cluster.ccs:
cluster {
  lock_gulm {
    ....
    lt_high_locks = <int>
  }
}

The highwater mark is an attempt to keep the amount of memory lock_gulmd 
uses down.  When the highwater is hit, the lock server tells all gfs 
mounts to try and release locks.  It does this every 10 seconds until 
the lock count falls below the highwater mark.  This requires cycles, 
and so not doing it means less cycles used.  The higher the highwater 
mark is, the more memory the gulm lock servers and gfs will use to store 
locks.  The number is just the count of locks (in <=6.0) and not an 
actual representation of ram used.

In short summery, in your case, a higher highwater mark may give some 
performance gained, at the loss of some memory available to other programs.

</snip>

I just bounced the storage servers using the lt_high_locks directive as above. The cluster.ccs looks like the following:
cluster {
        name = "hopkins"
        lock_gulm {
                servers = ["front-0", "front-1", "enigma"]
        }
        lt_high_locks = 2097152
        heartbeat_rate = 30
        allowed_misses = 4
}

gulm_tool getstats front-1:lt000 returns the following:

[root at front-0 root]# gulm_tool getstats front-1:lt000
I_am = Master
run time = 831
pid = 4073
verbosity = Default
id = 0
partitions = 1
out_queue = 0
drpb_queue = 0
locks = 80640
unlocked = 9267
exclusive = 19
shared = 71354
deferred = 0
lvbs = 9274
expired = 0
lock ops = 1805398
conflicts = 3
incomming_queue = 0
conflict_queue = 0
reply_queue = 0
free_locks = 87162
free_lkrqs = 60
used_lkrqs = 0
free_holders = 125909
used_holders = 81895
highwater = 1048576


Unless I'm mis-reading this, the lt_high_locks directive didn't do anything, unless the bottom number will change once it's breached?

My apologies to the list for my verbosity, btw - I'm just under the gun trying to get this stable and working.

--
Jerry Gilyeat, RHCE
Systems Administrator
Molecular Microbiology and Immunology
Johns Hopkins Bloomberg School of Public Health
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3618 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20050215/fbd93225/attachment.bin>