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

Re: OpenLDAP in large environment


Thanks for the RAM suggestion. I have already been through the pages you
mentioned on your site and have shamelessly borrowed some of the
configuration options mentioned :o)

Did you have any problems with regards to interoperability with client
programs and OpenLDAP 2.2.19?? (Courier-Imap seemed to be causing some
issues although that software has been a problem child of late anyways so
it might just be a courier problem).

Did you have to do any management of the BDB backend using the BDB tools??
The most painful part of OpenLDAP 2.2 (having moved from 2.0) is having to
manage the BDB side of things as well as the LDAP side of things. I have
also found that openldap rpms bundle and complie its own BDB software into
the ldap package and do not use the system librabries for bdb. In OpenLDAP
2.2.19 the BDB is 4.3 whereas the latest rpm version available is only bdb
4.2 so system utility files such as db_stat do not work (as they are 4.2
versions and the database is 4.3).

Might have to move away from rpms. Here is a copy of our slapd.conf and
DB_CONFIG just for your info. If you can see any glaring stuff ups or would
like to offer any opinions please let me know.

allow bind_v2

threads 64
schemacheck off
idletimeout 30

database        bdb
cachesize       20000
idlcachesize    20000
sizelimit       250000
#checkpoint      1024   5

index   uid             eq
index   uidNumber       eq
index   gidNumber       eq
index   memberUid       eq
index   ou              eq

index   cn              pres,eq,sub
index   sn              pres,eq,sub
index   objectclass     pres,eq

index   member                  eq
index   mailAlternateAddress    eq
index   mailLifeLongAddress     eq
index   mailDefaultAddress      eq
index   mailHost                eq
index   mail                    eq
index   employeeNumber          eq

index   relayAllow              eq
index   relayDomain             eq

index   default                 sub

loglevel 0
lastmod on

set_lk_detect DB_LOCK_DEFAULT
set_lg_max 10485760
set_cachesize   0       52428800        0
set_lg_regionmax 262144
set_lg_bsize 2097152
set_lg_dir /var/lib/ldap
# Automatically remove log files that are no longer needed.
# Just use these settings when doing slapadd...
#set_flags DB_TXN_NOSYNC

Thanks for the help.
David Brown
CSM Technology
99 Frome St,
Adelaide SA 5001
Email: david.brown@csm.com.au

             <quanah@stanford.                                          To 
             edu>                      David.Brown@csm.com.au,             
             09/12/2004 12:37                                           cc 
                                       Re: OpenLDAP in large environment   

--On Thursday, December 09, 2004 10:33 AM +0930 David.Brown@csm.com.au

> We have an OpenLDAP database that consists of approx 35,000 CNs (users,
> posixGroups, groupOfNames) and we anticipate that when fully populated
> database will have about 200,000 CNs.
> It is running on OpenLDAP 2.2.13 (with back-bdb) and Fedora Core 3 (after
> having corruption problems with OpenLDAP 2.0 back-ldbm on RedHat
> Enterprise 3). The servers it is running on are Dual P4 Xeon 3.06Ghz with
> 1Gig RAM and 2x36Gb HDD RAID1, although the SCSI RAID controller
> performance is known to be ordinary.
> Just wondering if anyone out there has any tips on how to get a database
> of this size performing reliably and quickly. (ie slapd.conf options,
> DB_CONFIG settings, ext2 mount options etc). I have searched around on
> google, the berkeley db site, the OpenLDAP archives and website and found
> some information but i'm interested in other users opinions and
> experiences.
> There are some performance and stability issues at the moment but i'm
> hopeful they are related to not having the various components tuned to
> work with a database of this size.
> Any help or info muchly appreciated.


Stanford has had an OpenLDAP deployment running since April 2003 with
approximately 350,000 CN's.  It contains user account data (posix, etc) and

user personal data (addresses, phone numbers, etc) as well as a variety of
other information.  I do suggest upgrading to a later version of OpenLDAP
(My preference is 2.2.19 given the patches it included).

On the hardware side, I would generally suggest more RAM (We run our BDB
Cache at 2 GB), but that in part depends on your indexing.

You may also wish to read through my Stanford OpenLDAP website:



Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html