----- Original Message -----
On 10/12/2011 05:41 PM, Rich Megginson wrote:
> Thanks.
>
> The select/poll are the server basically idle, waiting on a
> condition
> variable for new work to perform.
>
> You can eliminate many of these by decreasing your cn=config
> nsslapd-threadnum setting. The default is 30, but you may find
> better
> performance by setting to somewhere around 2 times the number of
> cpus/cores you have on your machine (but at least 8).
Yeah, I knew what the select/poll calls are, but I will look at
decreasing the number of threads to a more suitable number. Are
these
threads bound to a specific connection or is it a thread pool that
gets
requests delegated to it from the open connections?
It is essentially a thread pool, although it has a bit more logic than that.
> Do you know if any of these come from a period of time during which
> the server is consuming a lot of CPU?
Yes these were taken starting ~1 second before the spike and going ~2
seconds after. It's easy to start monitoring right before the event
when the leading edge to leading edge time is exactly 5 minutes!
Ok, thanks. I am investigating.
> No, should not be a problem. And it is standard - many apps do
> this
> (e.g. a web service that uses ldap for auth will not want to
> open/close a connection for every single user - it will typically
> use
> a connection pool of already open and possibly idle connections).
Our app doesn't really use a pool in the traditional sense... just
one
connection bound as a given user for that user's session... but I'm
glad
to hear that it shouldn't be the problem.
Thanks,
Justin