Date: Tue, 11 Dec 2012 19:57:18 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Richard Sharpe <rsharpe@richardsharpe.com> Cc: freebsd-hackers@FreeBSD.org, Alfred Perlstein <bright@mu.org>, Andre Oppermann <andre@FreeBSD.org> Subject: Re: Possible obscure socket leak when system under load and listener is slow to accept Message-ID: <20121211155718.GR48639@FreeBSD.org> In-Reply-To: <1355075850.6752.15.camel@localhost.localdomain> References: <50C3D22D.3060008@freebsd.org> <1355015131.6752.12.camel@localhost.localdomain> <50C4475D.9020300@mu.org> <1355075850.6752.15.camel@localhost.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Dec 09, 2012 at 09:57:30AM -0800, Richard Sharpe wrote:
R> > lsof and sockstat can be helpful. lsof may be able to help determine if
R> > there's a leak because it MAY will find sockets not associated with a
R> > process.
R> >
R> > Hope this helps.
R>
R> Thanks Alfred. After following through the call graph and confirming
R> (with the code) that it was correct, I am now pretty convinced that I
R> was wrong in assuming that it was a socket leak.
You can always check number of socket allocations in kernel via:
vmstat -z | grep ^socket | awk '{print $4}'
If you can't establish a scenario when the number infinitely grows,
then there is no leak.
--
Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121211155718.GR48639>
