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@xxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx >> https://admin.fedoraproject.org/mailman/listinfo/389-users > > -- > 389 users mailing list > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
