We're not doing any tar/backup of the filesystem, so I don't think that this is the issue. There are a *large* number of small files (but the files per directory are kept small). I'm not sure if that has anything to do with this. There are no abnormal messages in /var/log/messages. The lockspace output that I gave you is from a client, not the lock master. Let me know if there is any more information that I might be able to provide. We have a GFS service request open, but it doesn't seem to be getting very far :-( -----Original Message----- From: linux-cluster-bounces@xxxxxxxxxx [mailto:linux-cluster-bounces@xxxxxxxxxx] On Behalf Of Wendy Cheng Sent: Wednesday, March 08, 2006 1:21 PM To: linux clustering Subject: Re: GFS load average and locking Stanley, Jon wrote: >2) The locking statistics seems to be a huge mystery. The lock total >doesn't seem to correspond to the number of open files that I have (I >hope!). Here's the output of a 'cat /proc/gulm/lockspace - I can't >imagine that I have 300,000+ files open on this system at this point - >when are the locks released, or is this even an indication of how many >locks that are active at the current time? What does the 'pending' >number mean? > > GFS caches locks and normally won't release them (for performance reason). However, we do find this could cause latency issue, particularly after back up and/or tar command where lots of locks are accumulated into one single node that previously issued the backup command. Judging by your description of read latency and number of "shared" locks in your lockspace output, we do have a new tunable in to-be-released-soon RHEL3 Update 7 that allows admin to purge the locks. This seems to help several of (beta) customers to resolve their latency issues. Other than this, do you find any error messages in your /var/log/messages file ? -- Wendy -- Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster -- Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
