[389-users] Re: Lock table is out of available lock entries

On 8/9/21 8:09 AM, Kees Bakker wrote:
> Hi,
>
> When my dirsrv was trying to compact the databases I was getting this
> error
>
> [07/Aug/2021:23:59:02.715984489 +0200] - NOTICE - bdb_compact -
> Compacting databases ...
> [07/Aug/2021:23:59:02.765932397 +0200] - NOTICE - bdb_compact -
> Compacting DB start: userRoot
> [07/Aug/2021:23:59:03.518175414 +0200] - NOTICE - bdb_compact -
> compactdb: compact userRoot - 417 pages freed
> [07/Aug/2021:23:59:03.576427786 +0200] - NOTICE - bdb_compact -
> Compacting DB start: ipaca
> [07/Aug/2021:23:59:03.659941533 +0200] - NOTICE - bdb_compact -
> compactdb: compact ipaca - 419 pages freed
> [07/Aug/2021:23:59:03.718445310 +0200] - NOTICE - bdb_compact -
> Compacting DB start: changelog
> [08/Aug/2021:00:00:40.807571334 +0200] - NOTICE -
> NSMMReplicationPlugin - changelog program - cl5CompactDBs - compacting
> replication changelogs...
> [08/Aug/2021:00:00:54.309357211 +0200] - ERR - libdb - BDB2055 Lock
> table is out of available lock entries
> [08/Aug/2021:00:00:54.726504736 +0200] - ERR - bdb_compact -
> compactdb: failed to compact changelog; db error - 12 Cannot allocate
> memory
> [08/Aug/2021:00:00:54.801571421 +0200] - ERR - libdb - BDB2055 Lock
> table is out of available lock entries
> [08/Aug/2021:00:00:54.876618702 +0200] - ERR - NSMMReplicationPlugin -
> changelog program - cl5CompactDBs - Failed to compact
> a797bb0b-be1d11eb-88c0b677-613aa2ad; db error - 12 Cannot allocate memory
> [08/Aug/2021:00:00:57.253006449 +0200] - NOTICE - bdb_compact -
> Compacting databases finished.
>
> There are about 402k entries in cn=changelog.
>
> I have a few questions
> 1) is it normal to have so many entries in cn=changelog? On another
> replica I have almost 3M entries Isn't this cleaned up?
> 2) the number of locks is 50000 (there are two config items). Should I
> increase that number? If so, increase to what?
> 3) is there maybe something else going on, causing the exhaustion of
> the locks?

Ok, so by default there is no changelog trimming enabled.  So the
changelog will grow without bounds, which is bad.

I recommend setting up the changelog max age to 7 days:

https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/trimming_the_replication_changelog

Once that the trimming cleans up the changelog the database compaction
should work without issue.  You can also increase the database locks to
1 million (that does require a restart of the server to take effect).

HTH,

Mark

--
Directory Server Development Team
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure