OpenLDAP performance issues

Dieter Kluenter dieter at dkluenter.de
Mon May 16 11:29:04 CEST 2005


Hello Martin,

Martin Konold <martin.konold at erfrakon.de> writes:

> Am Donnerstag, 12. Mai 2005 09:16 schrieb Dieter Kluenter:
>
> Hi Dieter,
>
>> > I can imagine how these suboptimal config options can hurt the
>> > performance but I fail to see why OpenLDAP or the db is hanging under
>> > high load with these settings.
>>
>> Running out of i/o's and small thread pool are some possible reasons. See
>> options sockbuf and threads in slapd.conf(5)
>
> Is this really documented behavior of OpenLDAP that in case it runs out of 
> resources like i/o's and the thread pool it starts to hang instead of 
> reacting with both warning/error logs and degrades performances??

Well, as usual with OpenLDAP, the documentation is the source code.:-)
Slapd is waiting to get free resources until timeout and reports an
unwilling to perform.
There are a few issues operating system dependend. Solaris allows as
default only 1024 file descriptors to nonpreviledged users, while on
Linux you may find a restriction in providing threads, depending on
the distribution and kernel. (In particular RH)
To my experience, a well configured slapd never required more than 12
threads and I did heavy load tests with charge and slamd.

>> > To me this definitly looks like a bug in OpenLDAP or the underlying db!
>> > How can the write synchronization be disabled?
>>
>> It is an configurable option in slapd.conf (dbnosync) and DB_CONFIG
>> set_flags DB_TXN_NOSYNC.
>
> What is the default? Are you suggesting a change to the current settings in 
> CVS?

The default is to synchronize write operations, but it will speed up
bulk load with slapdadd if synchronization is of and no, I'm not
suggesting to set DB_TXN_NOSYNC as default.

By the way, there has been a thread on the cyrus-imapd mailinglist
with regard to increased imapd performance, the recommendation is to
set additonal cachesize in a DB_CONFIG file. sic

> In case please provide a patch I will happily apply as I start to be really 
> confused about OpenLDAP and its run time behavior. Actually I start to doubt 
> if OpenLDAP is the right choice for larger installations.

Actually, it is not an easy task to configure openldap to meet
individual system requirements, but I have set up a few servers with
up to 50,000 entries for mail routing and sasl authentication via
auxprop ldapdb, as well as database backend for bind-9.3, this systems
manage up to hundred searches per second. Just to give you an example
of a well tuned slapd (2.2.24) on my machine with about 8,000 entries.

time ldapsearch -x -H ldapi:/// -b ...

real    0m0.010s
user    0m0.001s
sys     0m0.003s


-Dieter

-- 
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:01443B53




More information about the users mailing list