On Fri, Nov 04, 2005 at 06:45:48PM +0100, Andre Oppermann wrote: A> >This isssue is seen on 3 different PCs running recent -current, clients A> >for a FreeBSD-6 NFS server (same problem when the NFS server is NetBSD). A> >All 3 clients have a small RAM, which may be a cause for faster apparition A> >of the issue. A> A> Hmmm... There are way too many in the packet cache (zone). Normally they A> should get free'd back into the mbuf and cluster zones if there are too A> many. A> I have to track down why UMA isn't doing that. I can easily reproduce the following situation: glebius_at_morannon:~:|>vmstat -z | grep mbuf mbuf_packet: 256, 0, 18446744073709526976, 24896, 68208 mbuf: 256, 0, 25026, 68, 470970 mbuf_cluster: 2048, 25280, 25280, 0, 25280 mbuf_jumbo_9k: 9216, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0 glebius_at_morannon:~:|>netstat -m 386/24964/25350 mbufs in use (current/cache/total) 384/24896/25280/25280 mbuf clusters in use (current/cache/total/max) 0/5/6576 sfbufs in use (current/peak/max) 864K/56033K/56897K bytes allocated to network (current/cache/total) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines In this state any cluster allocations fail. All I need to do is to download several Mb via bge(4) NIC. Backing out your changes fixes the problem. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPEReceived on Fri Nov 04 2005 - 22:53:32 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:47 UTC