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

Re: Maximum size of the primary thread pool

Rajarshi Chaudhuri wrote: 
Thanks Howard - I'll vary the pool size and watch the impact under load.


One more question regarding threads - is there a relation between the
concurrency directive and the threads directive in slapd.conf?

Maybe, maybe not. On most systems the concurrency directive is a no-op. On a POSIX-thread based system, this value is passed to pthread_setconcurrency. This setting only means something if the underlying thread model is M:N, i.e., the number of user threads differs from the number of kernel threads. This was true on some versions of Solaris, as I recall. I don't know any other examples offhand.

Rajarshi Chaudhuri
Genesys Telecommunications Lab, Inc
rajarshi@genesyslab.com
650.466.4860


-----Original Message-----
From: Howard Chu [mailto:hyc@symas.com] Sent: Thursday, February 08, 2007 3:45 PM
To: Rajarshi Chaudhuri
Cc: openldap-software@openldap.org
Subject: Re: Maximum size of the primary thread pool

Rajarshi Chaudhuri wrote: 
Hi,



Maximum size of the primary thread pool - the default is 16. Is it recommended to increase this value to higher ones like 32/64 etc.

We would never recommend any particular value for any particular
purpose. Without knowing the specifics of a system environment and usage
patterns, such recommendations would be meaningless.

Is there any loose relation between the RAM and OS and the thread pool
size
that I need to consider.

Yes, each thread uses 4 or 8MB of memory for its runtime stack. (8MB on
64 bit machines). Plus there are a variety of other modules that allocate
things on a per-thread basis.

Simply, is there any guideline on this thread pool size and it's implications?

The guideline is "test your server at varying configurations and choose
what works best for you." The effectiveness of threading varies with machine architecture, OS revision, and C library revision. Increasing the thread

count eventually reaches a point of zero-gain as the thread scheduling overhead starts to overshadow the time spent actually executing user
code. This is a fundamental feature of threading, on any system with any
software.

Rajarshi Chaudhuri
Genesys Telecommunications Lab, Inc
rajarshi@genesyslab.com <mailto:rajarshi@genesyslab.com>




--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  Chief Architect, OpenLDAP     http://www.openldap.org/project/