I had this problem a while back and updated the number of locks, but I couldn't get
the number of locks to actually change for real until I reimported the database. I
continued to get lock-related issues, even though I think the reported number of locks did
change, until the database was reimported.
Hopefully you won't run into that, but if you still get lock errors, that is one way
to make it work.
Regards,
Russ.
On Apr 14, 2014, at 12:12 PM, Noriko Hosoi <nhosoi(a)redhat.com>
wrote:
Michael R. Gettes wrote:
> ok, this appears to be user error. Sorry.
>
> i am still curious if this only need be done on replicated masters and not the
read-only replicas or must this be configured on all servers.
Glad to hear it was ok. I suggest to set 30000 on all servers since the deletion is
replicated to each read only replica and the DB behaves in the same way.
Thanks,
--noriko
>
> thanks!
>
> /mrg
>
> On Apr 14, 2014, at 14:22, Michael R. Gettes <gettes(a)gmail.com> wrote:
>
>> I am using 389-Directory/1.2.11.29 B2014.094.2116
>>
>> when deleting a large group (let’s say members > 25000) we see the following
error in the errors log
>> (which yields an Operations Error (err=1) back to the ldap client) and creates an
object with
>> dn:
nsuniqueid=cef92c21-b69711e3-8a25d834-1f7e47a1,CN=CommunityBLAH,ou=BLAH,DC=BLAH
>>
>> [14/Apr/2014:13:21:49 -0400] - libdb: Lock table is out of available lock
entries
>> [14/Apr/2014:13:21:49 -0400] - idl_new.c BAD 22, err=12 Cannot allocate memory
>> [14/Apr/2014:13:21:49 -0400] - database index operation failed BAD 1130, err=12
Cannot allocate memory
>> [14/Apr/2014:13:21:49 -0400] - database index operation failed BAD 1140, err=12
Cannot allocate memory
>> [14/Apr/2014:13:21:49 -0400] - database index operation failed BAD 1230, err=12
Cannot allocate memory
>> [14/Apr/2014:13:21:49 -0400] - database index operation failed BAD 1030, err=12
Cannot allocate memory
>>
>> after investigating the error message I tried to increase the number of locks
according to the documentation in section 2.5 of the admin guide “Lock Files” by setting
nsslapd-db-locks to 30000. I notice in cn=database,cn=monitor,cn=ldbm
database,cn=plugins,cn=config the attribute nsslapd-db-configured-locks does not change -
it was 10000 before I set it to 30000 and it remains 10000.
>>
>> Is this expected behavior? I can’t see any other indication my change has taken
effect (I do see my change in cn=config,cn=ldbm database,cn=plugins,cn=config).
>>
>> Also, if I set this attribute (nsslapd-db-locks) on my multi-replicated masters
to resolve this problem, do i need to set it on my non-master servers?
>>
>> Many thanks!
>>
>> /mrg
> --
> 389 users mailing list
> 389-users(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users