I'm running kernel version 2.2.14 as a firewall with moderately high load.
After a few hours, i start getting "dst cache overflow" log messages. That
apparently comes from rt_garbage_collect in route.c
I have seen a few discussions about this in the archives, but nothing ever
seemed too conclusive.
One suggestion was that the kernel needed a patch which changed the line
rt_del(hash, rt) to
rt_del(hash, rth)
But that appears to be in my kernel, that is if it's in the code for
ip_rt_redirect.
Another suggested a problem where thousands of connections were stuck in
LAST_ACK state, presumably keeping the cache entry tied up and therefore
not eligible to expire. But I am only seeing a few connections in this
state - i.e., this doesn't appear to be what's causing my problem.
Anyone out there have any further information or insight into this?
One thing that concerns me is that rt_garbage_collect will only make one
pass through the main loop while in_interrupt() ... thus perhaps that is
why it doesn't make it's goal of getting the cache entries below
ip_rt_max_size. if i am under heavy load, perhaps i am spending too much
time in_interrupt() which is why I can't trim down the cache sufficiently??
Or does this perhaps sound like a memory leak or something?
Thanks for any insight.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
