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

RE: Memory and CPU usage



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

> Adam Williams wrote:
> >>>I see a lot of memory problems with back-bdb when a
> particular configuration
> >>>is set to allow too many threads.
> >>
> >>I've never specified a threads statement in slapd.conf. The
> default is 32
> >>threads. Is that too high on some machines?
> >
> >
> > Yes, my master runs at 9.  Stress testing shows a peak at 8
> - 10,  so I
> > picked 9.  (This is a 2xPro200 with 384Mb and UW SCSI,
> LDAP database
> > striped across two drives.  Albeit it isn't a current machine,  but
> > testing newer machines shows that threads seems to top out
> about ~12 on
> > x86 boxes).
>
> <snip/>
>
> My server runs 27 threads. I've the default maximum (32). I
> think 27 are
> too much, but I'm not sure if it is save to change the maximum to
> something lower (eg. 10 or so)

I've found a misfeature in OpenLDAP's threadpool manager that caused it to
spawn threads much more often than necessary, causing it to quickly reach the
max thread limit. This has been fixed in the CVS HEAD. With this patch the
number of threads that slapd spawns will more closely reflect the load it's
experiencing. Preliminary testing shows that thread utilization is much
improved, as well as overall throughput.

Before, slapd would often spawn a new thread for an incoming operation even
though there were existing threads available to handle it. This hurt
performance because of the cost of spawning an extra thread. The thread
spawning continued until the thread max was hit, when it was forced to re-use
existing threads. With this patch, existing threads are always used fully
before any new thread is spawned. For any server that isn't already running
at 100% utilization, this yields a very noticable performance gain (as much
as 2x faster on some of my tests), and also makes the max thread setting
slightly less critical for tuning.

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