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

Re: [Linux-cluster] dlm and IO speed problem <er, might wanna get a coffee first ; )>

On Tue, 8 Apr 2008, Wendy Cheng wrote:

> The more memory you have, the more gfs locks (and their associated gfs file
> structures) will be cached in the node. It, in turns, will make both dlm and
> gfs lock queries take longer. The glock_purge (on RHEL 4.6, not on RHEL 4.5)
> should be able to help but its effects will be limited if you ping-pong the
> locks quickly between different GFS nodes. Try to play around with this
> tunable (start with 20%) to see how it goes (but please reset gfs_scand and
> gfs_inoded back to their defaults while you are experimenting glock_purge).
> So assume this is a build-compile cluster, implying large amount of small
> files come and go, The tricks I can think of:
> 1. glock_purge ~ 20%
> 2. glock_inode shorter than default (not longer)
> 3. persistent LVS session if all possible

What is glock_inode? Does it exist or something equivalent in 
Isn't GFS_GL_HASH_SIZE too small for large amount of glocks? Being too 
small it results not only long linked lists but clashing at the same 
bucket will block otherwise parallel operations. Wouldn't it help 
increasing it from 8k to 65k?

Best regards,
E-mail : kadlec mail kfki hu, kadlec blackhole kfki hu
PGP key: http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address: KFKI Research Institute for Particle and Nuclear Physics
         H-1525 Budapest 114, POB. 49, Hungary

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