Re: Reducing inode cache usage on 2.4?
From: Marcelo Tosatti
Date: Fri Dec 17 2004 - 13:12:06 EST
On Fri, Dec 17, 2004 at 05:26:20PM +0000, James Pearson wrote:
> I have an NFS server with 1Gb RAM running a 2.4.26 kernel with 2 XFS
> file systems with about 2 million files in total.
> Occasionally I get reports that the server is 'sticky' (slow
> read/writes) and the inode cache appears to consume most of the
> available memory and doesn't appear to reduce - a typical /proc/slabinfo
> output is below.
> If I run a simple application that grabs memory on the server, the inode
> and other caches are reduced and the server becomes more responsive
> (i.e. data rates to/from the server are restored to 'normal').
> Is there anyway I can purge the cached inode data, or any kernel
> parameters I can tweak to limit the inode cache or flush it more frequently?
> Or am I looking in completely the wrong place i.e. the inode cache is
> not the problem?
No, in your case the extreme inode/dcache sizes indeed seem to be a problem.
The default kernel shrinking ratio can be tuned for enhanced reclaim efficiency.
> xfs_inode 931428 931428 408 103492 103492 1 : 124 62
> dentry_cache 499222 518850 128 17295 17295 1 : 252 126
is what proportion of the VFS queues we will scan in one go.
A value of 6 for vm_vfs_scan_ratio implies that 1/6th of the
unused-inode, dentry and dquot caches will be freed during a
normal aging round.
Big fileservers (NFS, SMB etc.) probably want to set this
value to 3 or 2.
The default value is 6.
Tune /proc/sys/vm/vm_vfs_scan_ratio increasing the value to 10 and so on and
examine the results.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/