Red Hat Bugzilla – Bug 1028344
Slow ldapmodify operation time for large quantities of multi-valued attribute values
Last modified: 2014-10-14 03:52:07 EDT
what are the exact operations they process to add 100k members, is this a bulk add in one modify or are they added one by one.
can they provide their configuration and example data to reproduce.
ok this is one modify, but the add is split into many single operations, it should be faster if it is done like this:
the difference is that for teh single adds to check for the presence of the member a linear scan is done, but if more values are added at once a binary tree is used, which is faster. could you modify the add and test again
*** Bug 1068579 has been marked as a duplicate of this bug. ***
To verify this bug, see https://bugzilla.redhat.com/show_bug.cgi?id=839344#c3.
I could successfully add 100000 users as member for a single group in less than 3 secs. Hence, marking the bug as verified.
adding group: cn=g-100000
adding new entry "cn=g-100000,ou=groups,dc=example,dc=com"
Minor memory leak was found.
Functionality wise, there's no change.
Noriko, could you please provide additional verification steps for the minor memory leak?
If you run the test (comment 25) via valgrind and if the output does not include a function name attrlist_find_or_create_locking_optional, the fix is verified.
Hi Viktor, do you see "VERIFIED" in the status menu? Could you change it to "VERIFIED"?
Created attachment 924368 [details]
I repeated the test under valgrind. There are no mentions of attrlist_find_or_create_locking_optional in the output.
Marking as VERIFIED.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.