looks like the problem is fixed. As Rich suggested, the error message about memory was actually about insufficient number of locks. As i see from the stats, bdb needed about 45000 locks during the freeing of the changelog - 5 times more than the default value 10000. Here are the database stats:

1600    Initial number of locks allocated
100000  Maximum number of locks possible
45452   Current number of locks allocated
32      Number of current locks
43917   Maximum number of locks at any one time
3       Maximum number of locks in any one bucket

Thanks for helping me resolve this problem!



2015-06-20 13:22 GMT+02:00 Andrey Ivanov <andrey.ivanov@polytechnique.fr>:
Thank you, Ludwig and Rich.

Yes, i'm sure that the changes were effective. When starting the server says smth like
resizing max db lock count: 20000 -> 100000

And db_stat shows the correct new number of locks. Ok, i'll try to increase the locks further and see when the problem disappears.

2015-06-19 15:35 GMT+02:00 Ludwig Krispenz <lkrispen@redhat.com>:

On 06/19/2015 03:25 PM, Rich Megginson wrote:
On 06/19/2015 04:29 AM, Ivanov Andrey (M.) wrote:
Hi Noriko,



There are three MMR replicating servers. It's one month of uptime and the servers wanted to trim the replication log. Here is what i've found in error log on each of them :

1st server:
[18/Jun/2015:08:04:31 +0200] - libdb: BDB2055 Lock table is out of available lock entries
May not matter, but could you please try increasing the value of this db config parameter?  The default value is 10000.
dn: cn=config,cn=ldbm database,cn=plugins,cn=config
nsslapd-db-locks: 10000
Ok. I've increased nsslapd-db-locks to 20000 and reduced nsslapd-changelogcompactdb-interval to 3600 in cn=changelog5,cn=config to see the changelog free event more frequently. No change. I have still :

[19/Jun/2015:10:36:46 +0200] - libdb: BDB2055 Lock table is out of available lock entries
[19/Jun/2015:10:36:46 +0200] NSMMReplicationPlugin - changelog program - _cl5CompactDBs: failed to compact a45fa684-f28d11e4-af27aa63-5121b7ef; db error - 12 Cannot allocate memory



[18/Jun/2015:08:04:31 +0200] NSMMReplicationPlugin - changelog program - _cl5CompactDBs: failed to compact a45fa684-f28d11e4-af27aa63-5121b7ef; db error - 12 Cannot allocate memory
I don't thing there is any problem even if the DBs are not compacted.  It was introduced just to release the free pages in the db files.  But I'd also like to learn why the compact fails with ENOMEM here.
Ok, thanks.

I'm guessing that bdb returns ENOMEM when it runs out of locks.

I think the only remedy is to just keep increasing the number of locks until this error goes away.  I don't know how to estimate how many locks are required ahead of time.
I think compact can be consuming many locks, maybe for each of the pages in the cldb, and then there is this bug: https://fedorahosted.org/389/ticket/47934
did you verify that your changes have been effective ? try the db_stat:
db_stat -c -h /var/lib/dirsrv/slapd-<INSTANCE>/db/ | grep locks





--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users