Robert Watson wrote:
On Tue, 18 Apr 2006, Stephen Clark wrote:
I have discovered that if I disable quaqqa/ospfd then I don't lose mbufs!
This makes it appear that the mbuf leak is in the multicast routing logic.
In fact I lose mbufs even with the both system basically idle but with a 100
vpn/gre with multicast going on thru the gre then the vpn.
Any ideas on where to focus my continued investigation?
Thanks to everybody who has responded.
Steve,
Sorry not to have caught this thread earlier; I've been on travel for the last
few weeks. My general suggestion would be to try to narrow the code paths
traversed to try to eliminate as much code as possible from the search. It
sounds like you've done that pretty effectively :-).
Typically, memory leaks occur in edge error cases, where the memory is not
properly released, or ownership is unclear. My suggestion would be to add
counters (or look at existing counters where already present) and see if
there's an error case being triggered in about the same quantity that mbuf
leakage is occuring. Chances are, there's an error being returned and a
missing m_freem().
Based on your comments above, I might also pay attention to the routing socket
path -- the rate of leak could correspond to the routing daemons talking to
the network stack, rather than the rate of traffic. For example, it could be
that one of the routing messages is handled improperly resulting in a leak.
Unfortunately, tracking down memory leaks can be quite difficult, and tends to
require a combination of dogged persistence and luck...
Robert N M Watson
Robert,
Thanks for your response. I am in the process of moving our app to 6.
stable to see if the problem still exists. If it does then maybe I can't
generate some enthusiasm form the FreeBSD
community to take moew of an interest in the problem. I have a lot of C
experience but not with the *BSD network stack, still trying to get a
good understanding of the flow of the packets thru the stack.
Our next release will be based on 6 but that is months away. We have
some Athon 64 X2 we are putting in that will handling 100 to 200 vpn/gre
tunnels and right now ipintrq slowly grows
which eventually forces a reboot of the systems. Fortune 2000 companies
don't like see that happen.
Regards,
Steve
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
