Re: 2.1.17 performance issues

[Quanah Gibson-Mount <quanah@stanford.edu>]

--On Wednesday, April 16, 2003 1:34 PM -0500 John Madden 
<jmadden@ivytech.edu> wrote:

> > - number of entries in the directory
>
> ~5400
>
> > - indexes being used
>
> index objectClass eq
> index uid pres,eq
> index uidNumber pres,eq
> index campus pres,eq
> index mailacceptinggeneralid pres,eq
> index maildrop pres,eq
> index ctCalXitemId pres,eq
>
> > - cpu/ram
>
> It's varied since we've been flopping back and forth on machines, but the
> target machine is a dual Sparc II/400 with 1GB of RAM, Solaris 8.
>
> > - performance (btw, how does one measure this?)
>
> All queries start to get very slow and are eventually timed out.  Last
> night, I saw slapd get so bogged down that it wouldn't even completely
> respond to -INT (it'd refuse new connections but was never able to
> complete its other transactions, as far as I could tell).  I also have a
> script that runs the same filter 1000 times and spits back the number of
> queries per second, and with that script, I was able to see the
> performance drop from ~170 to ~8 queries/sec.
>
> And this is all running with "cachesize 10000000," although we don't have
> enough entries to fill that large a cache anyway, on top of the default
> bdb install.

John,

As per one of my previous emails, the cachesize directive in slapd.conf has 
no bearing on BDB.

Instead, one uses the DB_CONFIG file in the database directory.

See comments below:

--On Wednesday, April 16, 2003 11:18 AM -0500 John Madden 
<jmadden@ivytech.edu> wrote:

> > Again, I disagree.  In both the cases discussed here, I would say that
> > the  problems are most likely from configuration issues rather than
> > problems  with OpenLDAP performance.
>
> Care to provide us with some tuning documentation?
>
> I believe that the default configuration should perform well and continue
> to perform well over time.  Right now, 2.1.x seems to perform well to
> start but then degrades and never recovers, even after a restart.  If it's
> a configuration issue, I'd certainly like to see what was done to avoid
> it.
>
> For now, 2.0.27 on ldbm/GDBM is blazingly-fast.
> --On Wednesday, April 16, 2003 11:18 AM -0500 John Madden 
<jmadden@ivytech.edu> wrote:

> > Again, I disagree.  In both the cases discussed here, I would say that
> > the  problems are most likely from configuration issues rather than
> > problems  with OpenLDAP performance.
>
> Care to provide us with some tuning documentation?
>
> I believe that the default configuration should perform well and continue
> to perform well over time.  Right now, 2.1.x seems to perform well to
> start but then degrades and never recovers, even after a restart.  If it's
> a configuration issue, I'd certainly like to see what was done to avoid
> it.
>
> For now, 2.0.27 on ldbm/GDBM is blazingly-fast.

There is also some performance tuning documentation online at the OpenLDAP 
website for BDB.

Our configuration consists of:

cat /db/DB_CONFIG
set_cachesize 1 0 1
set_lg_regionmax 262144
set_lg_bsize 2097152
set_lg_dir /var/log/bdb
#Just use this setting when doing slapadd...
#set_flags DB_TXN_NOSYNC


This sets the cachesize to 1 GB with 0 additional KB with only 1 cache.

If you have less than 1 GB memory, then you need to do something like

set_lg_cachesize 0 (your cache size in MB * 1024 * 1024) 1

--Quanah


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