On 07/22/2015 04:54 PM, Martin Basti wrote:
On 22/07/15 16:52, Ludwig Krispenz wrote:
On 07/22/2015 03:56 PM, Martin Basti wrote:
I attached WIP patch to solve
I received several suggestions:
1) (implemented in patch) is to add the option --db-locks to
installer (maybe as hidden option)
2) Configure the nsslapd-db-locks to higher value as default (what is
the right value?)
this is a good question, I just looked into the ticket and the BZ, but
don't understand WHY it is running out of locks.
I think adding the option is ok to be prepared, but I would not change
the default before undestanding the reason for the lock consumtion and
a relation to the data.
Maybe we can also reduce the number of locks needed - do you have a
setup to show this failure ?
I don't have any setup, Petr1 did any testing with huge amount of user,
he may have got some VMs.
This happened during ipa-replica-install in installation with 160K users.
during replica initialization, there were:
libdb: BDB2055 Lock table is out of available lock entries
idl_new.c BAD 2, err=12 Cannot allocate memory
database index operation failed BAD 1050, err=12
errors in log.
I don't know anymore details, but increasing the number of locks in
/usr/share/dirsrv/data/template-dse.ldif template worked as a workaround.
Not sure if I remember it correctly, other instance of db locks error
was when I was adding a group of 30K users as a member of other group. I
think memberof plugin caused it.
3) Combination of 1and 2: set default higher value and also have
hidden option to allow configure higher number of locks during install
Comments are more than welcome :-)
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code