Bug 28098
| Summary: | mbus leakage in FreeBSD 4.3R somewhere | ||
|---|---|---|---|
| Product: | Base System | Reporter: | conrad <conrad> |
| Component: | i386 | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
In message <200106121228.f5CCSe678796@freefall.freebsd.org>, conrad@th.physik.u ni-bonn.de writes: >>Description: >There seems to be a mbuf leakage which can be triggered by userland programs ( >i.e.: gtk-gnutella run by our young folk :-) in 4.3R. > >The mbufs remain allocated AFTER THE PROGRAM TERMINATES! Further diagnostic information provided by Jan suggests that this is not an mbuf leak. The gtk-gnutella program seems to be very demanding on mbuf resources; the server process had 100-200 tcp sockets open, and on many socket transmit queue there were chains of 20-30 mbufs containig data (it must be doing lots of small writes). The mbufs are eventually slowly reclaimed, but I think those on the send queues can remain there for some time if the remote client stops responding or stops reading from the connection. I'll leave the PR open for now until the details are confirmed. There is also the issue of the page-faults when mbufs run out, but that is probably covered by another PR. Ian State Changed From-To: open->feedback Can this be closed? I think we determined that there was no mbuf leak, but that the application was just tying up a lot of mbuf resources in many send queues. State Changed From-To: feedback->closed Submitter says that this can be closed. |
There seems to be a mbuf leakage which can be triggered by userland programs (i.e.: gtk-gnutella run by our young folk :-) in 4.3R. The mbufs remain allocated AFTER THE PROGRAM TERMINATES! After the program was running one gets outputs like the following: [159]# netstat -m 1397/4224/6144 mbufs in use (current/peak/max): 1337 mbufs allocated to data 60 mbufs allocated to packet headers 69/806/1536 mbuf clusters in use (current/peak/max) 2668 Kbytes allocated to network (57% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines Normal operation looks like (we run a FreeBSD cluster and our machines are very stable otherwise...) [20]# netstat -m 80/624/6144 mbufs in use (current/peak/max): 77 mbufs allocated to data 3 mbufs allocated to packet headers 64/184/1536 mbuf clusters in use (current/peak/max) 524 Kbytes allocated to network (11% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines If one lets run the program for a longer time, the following error message is generated: Jun 12 11:54:20 wigner /kernel: looutput: mbuf allocation failed Letting it run even further, the system panics with a page fault and dumps core. However the core dump gives no reference to mbufs whatsoever (dumps etc. are available). Du to the broken '-M' of netstat I can give no mbuf output from the core... In addition, even if the system did not yet panic and the program is terminated (with the above err msg occuring several times) the box may panic after a while. This case I observed once, and the mbuf usage had gone back to something like 3000/6144/6144 before the crash Fix: unknown How-To-Repeat: run gtk-gnutella for a while