Hello,

I'm use an Openldap 2.3.11 withe SuSE (Novell) Linux ES 9.1.
The backend is a the Berkley Database (Sleepycat) 4.3.
The LDBM have'nt enough Performance - to much Datas.

Now I have a problem with the BDB. The BDB write to many transaction
logfiles (log.xxxxxxxxxx).
An delete operation of the logfiles is'nt good, I should use the
Berkley Tools to delete old logfiles.
But the Berkleytools are functionally only when the Openldap is
stopped. But I can't stop the Openldap in the Production.

Therefor I have build an DB_CONFIG:

set_cachesize 0 10485760 0
set_lg_bsize 2097512
set_lg_dir /home/LDAP/openldap_app/ main/db_logs
set_flags DB_LOG_AUTOREMOVE

The Flag DB_LOG_AUTOREMOVE should remove the old unused logfiles. But
no logfiles become deleted - every logfiles exist for all time.

The logfiles are written in the set_lg_dir directory from the DB_CONFIG
file - this is for me an evidence that the Backend used the DB_CONFIG
file.

On some Days I'm write so much Datas that the Backend produces 4 GB
logfiles in 24 hours - that's to much - I have only an 5 GB HDD.
And when the file system is full than stopped my application -
isn't good.

What can I do that no or not so much logfiles are written?

The Help is urgent, and I'm very appreciative for any help.
I havn't found an answer for my problem in the Sleepycat
Dokumentation or on sites in the internet.

I can do an flush or so one from the application ... the database are
written from Openldap.

Thank you very much
Frank

P.s.: Sorry form a bad English

Hi,

This is not correct. The db_archive utility is designed to be used
online.

I'm not sure that there's much you can do to reduce the amount of data
that is written. The key is to delete old log files that are no longer
needed.

For a log file to be deleted, it must not be needed for recovery or
transaction aborts. This means that there must be no transactions in
progress that were started before the end of the log file, and there
must be a checkpoint in a later log file. So the two things to check
are that transactions aren't running for too long, and that checkpoints
are running regularly.

If that is the case, you'll get a list of logfiles that can safely be
deleted by running db_archive in the environment directory.

Regards,
Michael.

Michael Cahill <mjc (AT) sleepycat (DOT) com> writes:

The user may need to use the checkpoint directive mentioned in the
slapd-bdb man pages.

--Quanah


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

Hi,

I have the same problem as the OP.

I tried different OS/BDB-Version combinations:
RH 3.6 with selfmade bdb 4.3, Debian sarge with
bdb 4.3.

Unfortunately, the hints (db_archive, setting snapshots according
to slapd-bdb(1)) doesn't help.

The db_archive utility does not work as documented:

1. db_archive without options called in the db or log directorey
never shows any output.
I restarted slapd several times and expected that
the "old" logiles could be deleted.

2. db_archive -s shows the datbase files. This shows
that my environment is setup correctly.

3. db_archive -v doesnt show any snapshots which should have
been taken place. I have called "db_snapshot -1".

Nevertheless, online backup and restore works great!
The verbose output of the "db_archive -c -v" doesnt help
in our case, though.

Any hint/information is highly appreciated!

Thanks,

Valentin

Hi Valentin,

You will need a DB_CONFIG file in the environment directory containing
a set_lg_dir line. Then run the db_archive utility in that directory
(the one containing __db.* and DB_CONFIG, not the log directory). It
should produce a list of obsolete log files.

If that list is empty, it may be that none of the log files are
obsolete -- this could happen if there was a very long running
transaction, for example. To check, look at the transaction statistics
(run "db_stat -t").

Regards,
Michael.

Hi,

thanks for the hint. It helps !!

I recompiled berkeley-db 4.2.52 and openldap 2.2.26
and now db_archive and db_stat -t works fine.

One *big problem* is left:
When i start slapd, db_stat -t shows that no transaction is active.
But after the first ldapsearch or access to the OpenLDAP server via
the perl API, there appears an active transaction.
This transaction never vanishes. Thus, the db_archive never offers
some more logfiles to be deleted.

Do you have any hints/ideas ?

Thanks in advance,

Valentin

--
for a direct email put a 'd' in front of the address which is shown

Valentin Rottmann <ba_db2 (AT) gmx (DOT) net> writes:

Upgrade to OpenLDAP 2.3.12, or apply the OpenLDAP specific BDB 4.2.52 patch that
is required for previous versions of OpenLDAP to get around long-running transactions.

OpenLDAP 2.2.28 and later have the pach in the build/ directory.

--Quanah

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