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

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&gt; 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