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

Re: performance issue

--On Tuesday, March 04, 2003 7:56 AM -0800 Mike Denka <mdenk@whidbey.net> wrote:

We've been gradually turning all our productions authentication and
authorization services over to OpenLDAP.  Using OpenLDAP-2.1.12 on a
RedHat 7.2 machine.  The hardware is 1 Gh/s processor with 512MB RAM.
Using Adaptec SCSI host adapters on RAID5.  Using an INTEL PRO/100 Fast
Ethernet Adapter.

The total number of BIND operations logged on the ldap server is a little
over 3 per second.  These operations represent authentication requests
from radius and attribute checking from our mail servers (correlating
usernames to home directories and permissions and mail quotas).

However, we are experiencing events in our ldap logs that report only
"deferring operation" from slapd.  These occur roughly once every three
seconds all the time.  Now we are ready to turn up our POP servers to
authenticate against our ldap server.  But when we do that we get the
following errors out of our (Solaris 9) mail (POP3) servers:


Mar  3 12:10:09 mail3 nscd[3874]: [ID 293258 user.error] libsldap:

Status: 81  Mesg: openConnection: simple bind failed - Can't contact LDAP


Mar  3 12:10:15 mail3 nscd[3874]: [ID 293258 user.error] libsldap:

Status: 7  Mesg: LDAP ERROR (89): Bad parameter to an ldap routine."

These errors start slowly and become more and more frequent until, after
5 or so minutes, the POP server quits working altogether.

Our slapd server is running the maximum number of threads (36) all the
time.  I notice that the connections between the mail servers and the
ldap server are reopening for each operation - probably not the most
efficient way of doing things but this is imbedded in Solaris (specifying
'ldap' in nsswitch.conf).

Any tips or suggestions about the cause of this apparent performance
problem.  What, exactly, does the "deferring operation" message from
slapd mean?  Certainly, I would think, there are those of you out there
who are hammering your slapd servers much harder than we are without
issue, correct?


In doing a number tests on our ldap machines to determine a good thread number, I can tell you that at least for our solaris servers, a thread value of 36 is too high. We've found 20 threads to be a good value on them. That results in a 62 query/second performance rate that is solid with 72 hosts pounding the machine at once. Boosting that to 36 threads causes many dropped connections and other problems. I suggest that you set up one linux machine separate from all your other machines, and pounding it while adjusting the thread value to find what works best for you. I had problems in my initial linux tests having anything more than 4 threads, but that was quite some time ago.


-- Quanah Gibson-Mount Senior Systems Administrator ITSS/TSS/Computing Systems Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html