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 <nho...@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 <get...@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@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
