threads <integer>
Specify the maximum size of the primary thread
pool. The default is 32.I haven't experimented with this at all. Let me know how it works out if you do.
Brian!
Matt wrote:
I'm running 2.0.25 It doesn't seem to peg the CPU.. just memory.... it's really only using around .1% of the CPU.. hardly touching it... but the memory is aweful. It is still responding to quieries.. but during busy times the swap goes crazy. We're getting more ram for the server.. but I wasn't sure if maybe I was missing some sort of optimization setting... it seems like those slapd's are always there.... they don't die.. and they all have run times of 7 hours.... so they must be spawned initially...
Clamscan and spamassasin are what is pegging my CPU but that's for another list :)
maybe I'll check the config file and see what I can find... This is all I see in ldap.conf: # $OpenLDAP: pkg/ldap/libraries/libldap/ldap.conf,v 1.4.8.6 2000/09/05 17:54:38$ # # LDAP Defaults #
# See ldap.conf(5) for details # This file should be world readable but not world writable.
#BASE dc=example, dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666
#SIZELIMIT 12 #TIMELIMIT 15 #DEREF never
I don't see anything in slapd.conf about it... hrmmmm
On Thu, 2003-04-03 at 10:07, Brian Clark wrote:
I had this same issue with LDAP not responding to queries and pegging the CPU. When I upgraded to OpenLDAP 2.0.27, that problem went away.
Brian!
Chris Wilkes wrote:
Is your LDAP server still responding to queries? I had a problem where a LDAP query would peg the CPU and never stop.
I tried using the DB4 tools like db_verify to examine the database files, but they weren't of much help. Finally gave up and deleted the files and recreated.
Chris
-- Brian Clark Vice President, Corporate Technology Protocol Marketing Group 1751 Lake Cook Rd. Suite 400 Deerfield, Illinois 60015 T 847-236-3414 F 847-236-3401
