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
