[Date Prev][Date Next]
Re: Connection-handling threads
On Mon, May 16, 2005 at 01:56:26PM -0400, matthew sporleder wrote:
> This may be a good case to work on tuning SLAPD_LISTEN.
I'm not sure tuning the backlog will help in our situation. We have
syncookies enabled, so listen(2) says that only completed connections (full
TCP handshake) will make it into the backlog. Our connection rate is
relatively low and stable, since the daemons using this cluster generally
connect once and perform operations on the same connection during the
Also, our load balancers perform health checks on individual servers every
few seconds. Any connections overflowing the listen() backlog will be
refused, and our load balancers aren't complaining about failed checks.
However, we *do* have a high number of open connections on each machine
(1200 is typical, perhaps 16-1800 at peak). The connection-handling thread
seems to be spending a lot of time accepting new LDAP operations from open
connections (select(), etc.) and dispatching them to worker threads.
> By the way, how are you determining that the connect handler is taking
> up the one cpu?
top(1) and ps(1) output show that thread consuming the bulk of one CPU,
while the worker threads are collectively consuming very little CPU.
John Morrissey _o /\ ---- __o
email@example.com _-< \_ / \ ---- < \,
www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__