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

More OpenLDAP questions

Thanks for everyone's help over the last couple of days!

** REPLICATION **
We moved to a replicated system yesterday (1 master and 2 slaves) and our mail server components authenticate against the two slaves and our updates are done against the master which receives no other traffic.  The slave servers have been up since the change but the master server has been going down from time to time.  I realized that my CGI was very good about unbinding but wasn't calling disconnect on the LDAP object when done so I've added this logic.  Could the failure to disconnect rather than just unbind cause such problems.  The CGI would also exit after running each time so the client endpoint to the LDAP server would go away with each run of the CGI.  I'd think that not disconnecting explicitly before exiting in the code wouldn't be ideal but wouldn't cause the slapd process great difficulty.  Would this sort of thing be likely to cause severe slapd problems?

Also, sometimes slurpd goes down and when it does I end up with a 2 GB (exactly) slurpd.replog file containing a great deal of redundant update data.  Has anyone else seen this?  Slurpd seems to consume 20% + of the CPU on a dual 2.4 Ghz. P4 system with 2 GB RAM while things are running normally.  This seems excessive.  Is this symptomatic of anything?

Again my system is Redhat Enterprise 3 ES with OpenLDAP 2.1.25 (back-bdb), BDB 4.2.52, and OpenSSL 0.9.7d.


** LOAD **
Our other problem is that under high load from the mail server we see that Maildrop claims it cannot connect to the LDAP server.  They are on the same system and Maildrop connects to localhost rather than going out over the network and back.  Maildrop's ldap_simple_bind_s is returning 81 (0x51) which is defined as the constant LDAP_SERVER_DOWN.  The server has been up for 24 hours now and is generally responsive though so this is confusing.  Under what conditions would slapd not accept a network connection?  Threads + backlog exceeded?

Thank you all again for your time and wisdom.

Jamey


James Courtney
InPhonic, Inc.