What triggers "No Buffer Space Available"?
Marc G. Fournier
scrappy at freebsd.org
Thu May 3 21:47:27 UTC 2007
-----BEGIN PGP SIGNED MESSAGE-----
- --On Thursday, May 03, 2007 19:28:56 +0100 Robert Watson <rwatson at FreeBSD.org>
> I generally recommend using a combination of netstat and sockstat. Sockets
> represent, loosely, IPC endpoints. There are actually two "layers"
> associated with each socket -- the IPC object (socket) and the protocol
> control block (PCB). Both are resource limited to pevent run-away processes
> from swamping the system, so exhaustion of either can lead to ENOBUFS.
> The behaviors of netstat and sockstat are quite different, even though the
> output is similar: netstat walks the protocol-layer connection lists and
> prints information about them. sockstat walks the process file descriptor
> table and prints information on reachable sockets. As sockets can exist
> without PCBs, and PCBs can exist without sockets, you need to look at both to
> get a full picture. This can occur if a proces exits, closes the socket, and
> the connection remains in, for example, the TIME_WAIT state.
> There are some other differences -- the same socket can appear more than once
> in sockstat output, as more than one process can reference the same socket.
> Sockets can also exist without any referencing process (if the application
> closes, but there is still data draining on an open socket).
> I would suggest starting with sockstat, as that will allow you to link socket
> use to applications, and provide a fairly neat summary. When using netstat,
> use "netstat -na", which will list all sockets and avoid name lookups.
'k, all I'm looking at right now is the Unix Domain Sockets, and the output of
netstat -> sockstat is growing since I first started counting both ..
This was shortly after reboot:
mars# netstat -A | grep stream | wc -l ; sockstat -u | wc -l
- From your explanation above, I'm guessing that the higher sockstat #s is where
you were talking about one socket being used by multiple processes? But, right
mars# netstat -nA | grep stream | wc -l ; sockstat -u | wc -l
sockstat -u #s are *down*, but netstat -na is almost double ...
Again, based on what you state above: "Sockets can also exist without any
referencing process (if the application closes, but there is still data
draining on an open socket)."
Now, looking at another 6-STABLE server, but one that has been running for 2
months now, I'm seeing numbers more consistent with what mars looks like
shortly after all the jails start up:
venus# netstat -nA | grep stream | wc -l ; sockstat -u | wc -l
So, if those sockets on mars are 'still draining on an open socket', is there
some way of finding out where? If I'm understanding what you've said above,
these 'draining sockets' don't have any processes associated with them anymore?
So, its not like I can just kill off a process, correct?
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy at hub.org MSN . scrappy at hub.org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)
-----END PGP SIGNATURE-----
More information about the freebsd-stable