Compact problem solved with nsslapd-db-locks: 1500000, should i keep it?

We had a problem today, one of our two 389 DS servers hanged showing the errors:

ERR - libdb - BDB2055 Lock table is out of available lock entries
ERR - NSMMReplicationPlugin - changelog program - _cl5CompactDBs - Failed to compact
db5f7bb9-ab0611e6-9bc8987f-40ec05bf; db error - 12 Cannot allocate memory

We redirected all the queries to our second 389 DS Server and started debugging the
problem.

It's the second time that this happens to us. We did our homework the first time, four
months ago, and didn't found any problem.

At that time, we just increased the number of open files and reviewed the documentation
about tunning nsslapd-db-locks (https://access.redhat.com/solutions/3217591). We set the
nsslapd-db-locks to 100000 as recommended.

But today, with a little more time, we reviewed the documentation about compacting the log
manually
(https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...).

We started to increase the nsslapd-db-locks, first up to 200000, then to half a million,
and at the end to 1.5 millions.

Every check failed but the last one. We have no error logs (nor an affirmative one), but
the database file in the 'changelogdb' folder went from 13GB to 2.8GB.

Is it reasonable to keep nsslapd-db-locks so high?

[Mark Reynolds]

On 4/26/21 8:33 AM, murmansk(a)hotmail.com wrote:
>  We had a problem today, one of our two 389 DS servers hanged showing
> the errors:
>
>  ERR - libdb - BDB2055 Lock table is out of available lock entries
>  ERR - NSMMReplicationPlugin - changelog program - _cl5CompactDBs - Failed to compact
> db5f7bb9-ab0611e6-9bc8987f-40ec05bf; db error - 12 Cannot allocate memory
>
>  We redirected all the queries to our second 389 DS Server and started debugging the
> problem.
>
>  It's the second time that this happens to us. We did our homework the first time,
> four months ago, and didn't found any problem.
>
>  At that time, we just increased the number of open files and reviewed the documentation
> about tunning nsslapd-db-locks (https://access.redhat.com/solutions/3217591). We set the
> nsslapd-db-locks to 100000 as recommended.
>
>  But today, with a little more time, we reviewed the documentation about compacting the
> log manually
> (https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...).
>
>  We started to increase the nsslapd-db-locks, first up to 200000, then to half a million,
> and at the end to 1.5 millions.
>
>  Every check failed but the last one. We have no error logs (nor an affirmative one), but
> the database file in the 'changelogdb' folder went from 13GB to 2.8GB.
>
>  Is it reasonable to keep nsslapd-db-locks so high? 
There is a bit of debate on this topic, but really the only impact of 
more db locks is that one of the private DB files will be larger (but 
it's not significant in size).  IMO I would say it's perfectly safe to 
keep it at that value.

Mark

>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-- 

389 Directory Server Development Team

Thanks for your answer Mark!!

We'll configure the same value on our second server.

[Nelson Bartley]

I don’t know about increasing dblocks, but that seems like the same crash
that was affecting our systems as well. We had two identical crashes like
that, and I recently updated all the packages in hopes that it was just a
bad linked library.

If we have the same crash after updating I’ll try and find more data. I
could get the crash dump data last time.



On Mon, Apr 26, 2021 at 23:20 <murmansk(a)hotmail.com&gt; wrote:

>  Thanks for your answer Mark!!
>
>  We'll configure the same value on our second server.
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>  
-- 
Sent from Gmail Mobile