Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 16 Mar 2015 17:01:45 -0700
From:      Charles Swiger <cswiger@mac.com>
To:        David Benfell <benfell@parts-unknown.org>
Cc:        questions@freebsd.org
Subject:   Re: sonewconn: pcb 0xfffff801efdd1000: Listen queue overflow: 31 already in queue awaiting acceptance
Message-ID:  <457B9A78-1A87-4CE9-BBD0-5813BDA352CE@mac.com>
In-Reply-To: <20150316234857.GA3587@home.parts-unknown.org>
References:  <20150316213018.GA97580@home.parts-unknown.org> <22987F08-3543-43BE-A06A-78E76437ADD2@mac.com> <20150316234857.GA3587@home.parts-unknown.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 16, 2015, at 4:48 PM, David Benfell <benfell@parts-unknown.org> =
wrote:
> On Mon, Mar 16, 2015 at 03:38:51PM -0700, Charles Swiger wrote:
>>=20
>> They aren't directly related.  You generally need to increase =
apc.shm_size
>> suitable for however many PHP processes you're running-- generally =
via mod_php
>> in Apache or fastcgi for nginx and the like.
>=20
> I *am* running a bunch of php-fpm processes. Is there a formula for
> calculating this?

There's an apc.php script which will look at your APC stats.

>> The listen queue overflow means that your system is failing to =
process
>> incoming requests fast enough to keep up.  The bottleneck could be
>> on a resource like CPU or memory, or serialization against a database
>> table, or something else.  (You'll want to identify the bottleneck.)
>=20
> Interesting. htop says I've got plenty of memory and CPU--it's a new
> server and I went big. That would seem to suggest mysql may not be
> performing well, which is a very strong possibility. Until relatively
> recently, I was trying to run on a VPS and then a rather small hosted
> server; I don't think I've revisited the mysql configuration since.
>=20
> Thank you very much. All this helps.

mysql is a likely candidate, particularly if it was an old setup and has
not been tuned for the workload.  For example, MyISAM is adequate for
read-mostly stuff, but table-level locking tends to become a real =
problem
if you have more than a single admin instance doing writes.

http://dev.mysql.com/doc/refman/5.7/en/table-locking.html

Regards,
--=20
-Chuck




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?457B9A78-1A87-4CE9-BBD0-5813BDA352CE>