ok, thanks. What i have empirically learned is to set the number of locks to be greater than the max number of members in a group. 30,000 wasn’t enough because i had some groups with 36K members. It would appear an internal lock is being used for each DN when processing a group object. I bumped the number up to 100,000 based on future projections for number of members in a group. If my empirical learning is right, this might be something useful (and fairly important) to document. In fact, I would recommend the dev team to dramatically increase the default of 10,000.
/mrg On Apr 14, 2014, at 15:12, Noriko Hosoi <[email protected]> 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 <[email protected]> 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 >> [email protected] >> https://admin.fedoraproject.org/mailman/listinfo/389-users > > -- > 389 users mailing list > [email protected] > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/389-users
