Date: Mon, 16 May 2016 21:47:48 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 209471] Listen queue overflow due to too many sockets stuck in CLOSED state Message-ID: <bug-209471-2472-vSaVbS1Usd@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-209471-2472@https.bugs.freebsd.org/bugzilla/> References: <bug-209471-2472@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209471 --- Comment #14 from Robert Blayzor <rblayzor@inoc.net> --- Will try tcpdrop the next time it happens. We normally can't catch it until= the health monitors pick it up as dead, thats' when we notice the kernel messag= es. Usually by that time a "kill -9" will not work on the process and the only = way to fix the problem is reboot. I'm still trying to figure out why we are affected by this issue and Bug 204426. Am I correct in that Bug 204426 is only VM memory related? If so, m= aybe I can jack up the physical memory to the VM and try turning VM off. AFAIK we're not doing anything special on the servers; just diskless boot V= M's, NFS root, a couple of memory disk filesystems (/etc and var, which do not g= row at all)... Just trying to figure out what in our environment is causing us = to see this A LOT. One would think these two bug (or same one) would be a major regression other people would run into. If not, why? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-209471-2472-vSaVbS1Usd>