RE: purpose of set_lg_regionmax

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Paul B. Henson

> What is the exact nature of set_lg_regionmax in the Berkeley
> DB, and when
> would one need to increase it? I have not found a good
> explanation.

There really isn't any good explanation.

> The documentation says:
>
> "The log region is used to store filenames, and so may need
> to be increased
> in size if a large number of files will be opened and
> registered with the
> specified Berkeley DB environment's log manager."
>
> I'm not sure what filenames this refers to. If I have a large
> number of
> indexes, do those count as filenames? I have seen a variety
> of different
> settings in the sample DB_CONFIG files in various postings, but no
> explanations as to how the values were determined.

Yes, every attribute that you configure for indexing uses one file to store
its index. There's also the id2entry and dn2id files which are always
created. WHat constitutes a "large number" in this case is unknown. The best
answer I got from Sleepycat is "it depends."
>
> I am currently running openldap 2.1.22 with db 4.1.25. Everything was
> working well until I tried to implement groups. We have approximately
> 14,000 groups with approximately 300,000  members. I have an
> equals  index
> on the member attribute. While trying to populate all of the
> members of the
> groups, I ran into a strange problem where my script would
> occasionally
> fail to find users while trying to add them to the group.
> After working on
> this for a while I tried to just completely delete a group
> and start over.
> I received a strange error about being unable to delete the
> index entry and
> it refused to delete the group.
>
> Figuring that perhaps the indexes were corrupt, I tried
> running slapindex
> with no success. I finally tried using slapcat to dump the
> database, but
> when I tried to reload it it would fail somewhere in the
> middle with region
> corrupt errors. While researching that error, I came across
> references to
> the subject configuration option. I'm not sure if it is related or not
> (although it coincidentally has something to do with regions).
>
> Thanks much for any help...

Whenever you start making wholesale changes like deleting and recreating raw
database files, you really really really need to run db_recover first.

There are no known bugs in 2.1.22's database handling code, so you shouldn't
need to resort to such drastic operations.

But you can certainly run into situations where things fail because you've
run out of BDB cache. In that case, checking db_stat -m will tell you some
useful things about your cache state, and you'll probably want to run
db_recover to destroy the existing cache so you can configure a larger one.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support