On Tue, Feb 08, 2005 at 01:37:16AM +0100, Anders Saaby wrote:
> Hi,
>
> On Tue, Feb 08, 2005 at 12:14:26AM +0100, Dave Chinner wrote:
> >How many inodes are cached? Can you dump out the xfs slabs from
> >/proc/slabinfo when this is occurring? i.e.
> >
> ># egrep "^(xfs|linvfs|dentry)" /proc/slabinfo
>
> Here is my slabinfo after heavy load:
>
> <SNIP>
> grep "^(xfs|linvfs|dentry)" /proc/slabinfo
>
> xfs_inode 417324 423464 512 8 1 : tunables 54 27 0 :
> slabdata 52933 52933 0
> linvfs_icache 417324 421421 544 7 1 : tunables 54 27 0 :
> slabdata 60203 60203 0
> dentry_cache 345650 401004 216 18 1 : tunables 120 60 0 :
> slabdata 22278 22278 0
> </SNIP>
>
> - xfs_inode, linvfs_cache and dentry_cache gets even higher after a longer
> test run.
So at this point, you've already got >400,000 cached inodes on a single
filesystem....
> >If you have a significant number of cached inodes, and you are
> >repeatedly missing the cache, then we will spend a significant
> >amount of time searching the cache...
>
> I have quite a lot:
> df -i:
> Filesystem Inodes IUsed IFree IUse% Mounted on
> /dev/sdb1 716043376 19405588 696637788 3% /mnt/xfs_test
>
> And part of my test is to relatively often miss the cache.
Uselessly chasing long chains in the hash is probably where the CPU
usage is coming from, then.
> - If that is the case, do you have any ideas to how I can get my system to
> perform better? (Performance gets very poor efter approx. two hours of heavy
> load.)
Seeing as you are running 2.6.11-rc3, you're in luck. Nathan's
inode hash tweaks were merged into -rc3, so you can increase the
size of the inode hash with a mount option. The mount option
is "ihashsize", and it specifies the width of the hash table.
i.e. `mount -o ihashsize=xxxxx /dev/sdb1 /mntpt`
I'm not sure what the default your filesystem will be using, but
a maximum of 16*PAGE_SIZE (=64k chains on i386/x86-64) applies to the
default setting.
If you specify a size this maximum does not apply, but if you
specify a value too large memory allocation for the hash will
silently fail and the size will be halved repeatedly until the
allocation succeeds.
HTH.
Cheers,
Dave.
--
Dave Chinner
R&D Software Engineer
SGI Australian Software Group
|