Well, backing out now is not really an option... But given my past history with NFS, and knowledge of this site I think I have a fair idea where the leak is... I think it is in the nfsv3 "commit" handler.
Why do I think this? Simple, this problem started when a user started running a large job on out origin 2k, prior to that our server had been up for 30-ish days sans any problems, since his start it requires a boot-a-day (mbuf clusters are up to 8k). Also supporting this is the fact that the clusters are used at a fairly constant rate. Now (following that hunch), I did a tcpdump against that host for tcp traffic, and noticed a fairly steady stream of "commit" NFS traffic. I realize none of this is a smoking gun, but that is where my "hunch" lies. How is mbuf cluster cleanyup done? If I knew I might have a shot in heck at locating this problem. BTW: updated netstat -m for the machine: 4855/5344 mbufs in use: 4848 mbufs allocated to data 7 mbufs allocated to packet headers 4774/4850/8704 mbuf clusters in use (current/peak/max) 10368 Kbytes allocated to network (97% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines That's alot of buffer ;) -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message