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

Re: thread problem OpenLDAP 2.1.8 + Solaris 9



--On Friday, November 08, 2002 3:59 PM -0800 "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> wrote:

At 08:55 AM 2002-11-08, Quanah Gibson-Mount wrote: 
although our performance testing from OpenLDAP-2.1.8 is is showing only
about 7 queries/sec answered (we need a minimum of 20 queries/sec
throughput).


That's awful low performance.  On relatively small systems,
performance in the 1000s of queries per second range is
easily achievable.   Likely you don't have the right
indices or the indexing is ineffective due to the number
of total entries.  In the later case, you might try
increasing the IDL sizes in back-bdb/idl.h.  You might
also look at BerkeleyDB environment settings.

Other things to look at:
       - ACLs... avoid unnecesary regex'ing
       - REGEX... make sure you are using a good REGEX library
               (some Solaris versions suck)
       - Logging (disable synchronous logging, only log minimal stuff)


Kurt,

Having now done much tweaking with openldap, we are now up to a dismal average of 14 queries/second with 20 hosts over a 74.5 minute period.

To refresh, we are running Openldap-2.1.8 on Solaris 8, with threads. Using Heimdal-0.5.1, cyrus-sasl-2.1.9, openssl-0.9.6g, and Berkeley DB 4.1.24.

Regex'ing in the ACL's has been removed as per a later email. Our ACL's are all quite specific. We have found no difference between having loglevel 0 and loglevel 256 in relation to performance.

Changing threads to anything larger than 32 causes continual GSSAPI failures with gss_accept_sec_context errors. Using concurrency with the threads setting does not fix this.

We have been able to fix slapd locking up over time by using an idletimeout of 30. slapd continues to lock up with this setting if threads is again changed to anything greater than 32.

When I change the IDL sizes in back-bdb/idl.h, GSSAPI authentication stops working at all, as it seems this makes it unable to find the SASL security properties. Do you have any further hints on this? I changed BDB_IDL_DB_SIZE to (1<<17) and BDB_IDL_UM_SIZE to (1<<18) together, and testing those changes singly, and all resulted in the same problem.

I am fairly positive we are indexing everything necessary. All we are doing right now is filtering on suseassunetid to find the sumaildrop attribute. Both of those attributes are indexed, as are objectClass, entry, uid, dc, and cn. Example query: ldapsearch -h <host> -b"cn=accounts,dc=stanford,dc=edu" suseassunetid=quanah sumaildrop

A few things we have noticed:

One: slapd spends a lot of time determining the ACL's for attributes, every single time a query is made, instead of caching the ACL's. I am interested in its #1523, but do not have access to the patches. Would it be possible to send them to me, so I can see if that improves our performance any?

Two: slapd will be very responsive and quick in its answers for a period of time, then will just hang for several seconds, or greatly slow down the rate at which it is returning queries. It will then pick up again, being quite responsive.

Examples of this:

Overall, the testing results show wide variations across
            segments of time in the query rate, leading to only averages
            calculated across long periods of time being reasonably
            reliable.

STATISTICS FROM THE CLIENT(S) SIDE

  Time Slice Starts: Mon Nov 25 13:11:50 2002
  Time Slice Ends:   Mon Nov 25 13:14:39 2002
  Number of Hosts:   1
  :
  :   Average: 6.5941 answers/second
  :   Total Answers Received: 1121
  :   Elapsed Time: 170 seconds
  :   Distribution:
  :      1 answers/second: 1 occurrences
  :      2 answers/second: 2 occurrences
  :      3 answers/second: 4 occurrences
  :      4 answers/second: 11 occurrences
  :      5 answers/second: 20 occurrences
  :      6 answers/second: 30 occurrences
  :      7 answers/second: 49 occurrences
  :      8 answers/second: 40 occurrences
  :      9 answers/second: 13 occurrences

  Time Slice Starts: Mon Nov 25 13:19:09 2002
  Time Slice Ends:   Mon Nov 25 13:20:57 2002
  Number of Hosts:   5
  :
  :   Average: 19.9083 answers/second
  :   Total Answers Received: 2170
  :   Elapsed Time: 109 seconds
  :   Distribution:
  :      0 answers/second: 4 occurrences
  :      1 answers/second: 1 occurrences
  :      5 answers/second: 2 occurrences
  :      7 answers/second: 2 occurrences
  :      8 answers/second: 3 occurrences
  :      10 answers/second: 1 occurrences
  :      11 answers/second: 1 occurrences
  :      12 answers/second: 4 occurrences
  :      14 answers/second: 2 occurrences
  :      15 answers/second: 2 occurrences
  :      16 answers/second: 4 occurrences
  :      17 answers/second: 7 occurrences
  :      18 answers/second: 9 occurrences
  :      19 answers/second: 1 occurrences
  :      20 answers/second: 2 occurrences
  :      21 answers/second: 6 occurrences
  :      22 answers/second: 7 occurrences
  :      23 answers/second: 8 occurrences
  :      24 answers/second: 9 occurrences
  :      25 answers/second: 8 occurrences
  :      26 answers/second: 9 occurrences
  :      27 answers/second: 6 occurrences
  :      28 answers/second: 6 occurrences
  :      29 answers/second: 4 occurrences
  :      30 answers/second: 1 occurrences

--Quanah

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