Re: Reducing inode cache usage on 2.4?
From: James Pearson
Date: Fri Dec 17 2004 - 19:34:47 EST
Marcelo Tosatti wrote:
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.
Thanks for the info - but doesn't increasing the value of
vm_vfs_scan_ratio mean that less of the caches will be freed?
Doing a few tests (on another test file system with 2 million or so
files and 1Gb of memory) running 'find $disk -type f', with
vm_vfs_scan_ratio set to 6 (or 10), the first two column values for
xfs_inode, linvfs_icache and dentry_cache in /proc/slabinfo reach about
900000 and stay around that value, but setting vm_vfs_scan_ratio to 1,
then each value still reaches 900000, but then falls to a few thousand
and increases up to 900000 and then drop away again and repeats.
This still happens when I cat many large files (100Mb) to /dev/null at
the same time as running the find i.e. the inode caches can still reach
90% of the memory before being reclaimed (with vm_vfs_scan_ratio set to 1).
If I stop the find process when the inode caches reach about 90% of the
memory, and then start cat'ing the large files, it appears the inode
caches are never reclaimed (or longer than it takes to cat 100Gb of data
to /dev/null) - is this expected behaviour?
It seems the inode cache has priority over cached file data.
What triggers the 'normal ageing round'? Is it possible to trigger this
earlier (at a lower memory usage), or give a higher priority to cached data?
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/