Quick practical observation re DBD default configuration

["Richard L. Goerwitz III" <richard@Goerwitz.com>]

This isn't a bug per se, but rather something implementors might
want to note:

When initializing OpenLDAP 2.2.17 with a BDB back end yesterday I
was loading several thousand objects into the database from an LDIF
using ldapadd.

I found that after a certain amount of time, I ran into transient
implementation-defined (80) errors adding objects.  When I utilized
the -c option to ldapadd, I found that after a few bombed adds these
errors would generally go away and objects would again go in just
fine.  An strace revealed a select() timeout was going on under the
hood.

The debug log showed that ldapadd seemed to be timing out waiting
for a lock to get relased in the buffer cache:

  slapd[27850]: bdb(dc=carleton,dc=edu): unable to allocate space
  from the buffer cache

I tried setting the buffer cache to 500k and found that doing this
alleviated the problem.  In DB_CONFIG, e.g., I used:

  set_cachesize 0 524288 0

The reason I post here is that normally one wouldn't expect an LDIF
load to cause all the available cache pages to end up being pinned.
I was also surprised to find the default cache size inadequate to
a task like an LDIF load.

As noted, I worked around the problem in question easily.  So this
is not a bug report per se.

I'm just hoping that the core developers will find this information
helpful.

--

Richard Goerwitz                               richard@Goerwitz.COM
tel: 507 645 7015