----- 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 > -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
