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=209471 --- 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 messages. 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, maybe 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 VM's, NFS root, a couple of memory disk filesystems (/etc and var, which do not grow 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? -- 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>