[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 ; )>

Wendy Cheng wrote:
Kadlecsik Jozsef wrote:

What is glock_inode? Does it exist or something equivalent in cluster-2.01.00?

Sorry, typo. What I mean is "inoded_secs" (gfs inode daemon wake-up time). This is the daemon that reclaims deleted inodes. Don't set it too small though.

Have been responding to this email from top of the head, based on folks' descriptions. Please be aware that they are just rough thoughts and the responses may not fit in general cases. The above is mostly for the original problem description where:

1. The system is designated for build-compile - my take is that there are many temporary and deleted files.
2. The gfs_inode tunable was changed (to 30, instead of default, 15).

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?

Worth a try.

Now I remember .... we did experiment with different hash sizes when this latency issue was first reported two years ago. It didn't make much difference. The cache flushing, on the other hand, was more significant.

-- Wendy

However, the issues involved here are more than lock searching time. It also has to do with cache flushing. GFS currently accumulates too much dirty caches. When it starts to flush, it will pause the system for too long. Glock trimming helps - since cache flush is part of glock releasing operation.

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