[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: OpenLDAP in large environment
Quanah,
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.
SLAPD.CONF
allow bind_v2
threads 64
schemacheck off
idletimeout 30
database bdb
cachesize 20000
idlcachesize 20000
sizelimit 250000
#checkpoint 1024 5
#dirtyread
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
DB_CONFIG:
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.
set_flags DB_LOG_AUTOREMOVE
# Just use these settings when doing slapadd...
#set_flags DB_TXN_NOSYNC
#set_flags DB_TXN_NOT_DURABLE
Thanks for the help.
______________________________
David Brown
RHCE MCP CCA
CSM Technology
99 Frome St,
Adelaide SA 5001
Email: david.brown@csm.com.au
Quanah
Gibson-Mount
<quanah@stanford. To
edu> David.Brown@csm.com.au,
openldap-software@OpenLDAP.org
09/12/2004 12:37 cc
PM
Subject
Re: OpenLDAP in large environment
--On Thursday, December 09, 2004 10:33 AM +0930 David.Brown@csm.com.au
wrote:
>
>
>
>
> We have an OpenLDAP database that consists of approx 35,000 CNs (users,
> posixGroups, groupOfNames) and we anticipate that when fully populated
the
> 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.
David,
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:
<http://www.stanford.edu/services/directory/>
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html