[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: runaway slapd threads



> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Xuehai Zhang

> hi,
> i wonder if the following message about the criteria of slapd
> multithreading mechanism has been answered yet. i could not found any
> following threads about it. i am also interested in the answer and will
> appreciate if someone tells me how.
> xuehai zhang

> ---original thread---------------
> could be found at
>
> http://www.openldap.org/cgi-bin/wilma_hiliter/openldap-software/200
204/msg00217.html?line=22#hilite
> ----------------------------------
>
> I am running slapd 2.0.23 (using the Debian sid binary packages), which is
> compiled with threads, on Linux 2.4.17. I am confused by slapd's threading
> model.
>
> I currently have 34 threads, but I thought that slapd maxed out at 32
> threads (I have not changed the threads parameter in
> slapd.conf). Furthermore, some of the threads are up to 4 days
> old; shouldn't they have been killed off by now?

In your 34 threads, there are 32 worker threads. There is one slapd listener
thread, and LinuxThreads itself creates one Manager thread.
>
> Could someone please explain the criteria for creating and destroying
> slapd threads? Does slapd maintain a pool to threads for re-use?

slapd uses a thread pool, and once a thread is added to the pool it stays
there. There is no provision for killing idle threads. Aside from the process
slot that's occupied, idle threads consume no system resources so there's
little point.

> Is it possible I'm not terminiating unused TCP connections fast
> enough? (Do v3 LDAP querries send a FIN packet when done?) If so, is there
> some way to tune the kernel to disconnect faster? Or is something else
> going on entirely?

There is nothing else going on. Questions about TCP or kernel behavior are
orthogonal to this topic. TCP FIN is sent on connection close by the TCP
implementation, higher level code never needs to deal with it. If the TCP
stack is broken, higher level code can do nothing to fix it.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support