> I've been running some squid benchmarks here using polygraph, and have
> found that 2.2.14 (or possibly squid 2.2.STABLE5) seems to have a huge
> inode leak.
>
> Though netstat only shows a couple hundred connections, and file
> descriptors are maxing out below 1000, my /proc/sys/fs/inode-nr is in
> the thousands! No matter how high I set inode-max, it will grow to fill
> it and well beyond. It's gone as high as 80000 before blowing up the
> box. The rate of growth is about 30-60 per second depending on how much
> data is flowing in and out on the network.
>
> I've tried downgrading to 2.2.13, with similar results. I've tried
> every 2.2STABLE version of squid (plus every conceivable patch) I could
> find, with no change. And I've tried ext2 and reiserfs partitions, no
> change.
>
> Anyone have thoughts on what I should be looking for to figure out what
> the culprit is? And/or how to fix it? I saw one mention of someone
> else having inode issues in 2.2.14, but no solution or further info.
>
> Some further info:
> tulip.c net
> 3 UDMA 66 hard disks (IBM and Maxtor)
> MVP3 motherboard (with the ATA66 chipset)
>
> Any help would be greatly appreciated. Please cc: my email address, as
> I'm not on the list.
What happens when you try to unmount filesystem?
If it doesn't let you to umount it, it's dentry leak.
If it unmounts, but writes 'Busy inode after unmount', it's inode leak.
If it unmounts and the number of inodes drops after umount, it's because
pruning dcache works badly.
If it unmounts and the number of inodes stays the same, it's leak in
socket inodes.
Mikulas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:25 EST