That is by far the largest example we have. We use groups with the uniquemember attribute linking to account entries and more than a few of the groups have tens of thousands of values for uniquemember. We create more of these groups regularly and it will be a problem for it to take many hours to construct such a group versus seconds/minutes with Sun DS. Our metadirectory process does not use ldapadd to create the group pre-populated, the group is created and then ldapmodify is run to add members. Three times a year at the change of semester, many thousands of group membership changes are processed and we already have a problem with it taking multiple days to process the entire set...
We also have large quantities of eduPersonEntitlement on account records, but those sets are not nearly as numerously populated. I can delete and re-add the eduPersonEntitlement attribute across 110,000 records in about 40 minutes (20 minutes each way -- with 389). Russ. On Apr 19, 2012, at 10:18 AM, Rich Megginson wrote: > On 04/19/2012 10:50 AM, Russell Beall wrote: >> >> Thanks for the tips. I scanned the dse.ldif for those plugins and I found >> definitions for them all, but they all have nsslapd-pluginEnabled: off. >> >> There is something special about the uniquemember attribute that requires >> additional processing different from other attributes... Ldapmodify of >> other attributes runs pretty quick. > > Is uniquemember the only attribute using large numbers of multiple values in > ldapmodify operations? > >> >> Regards, >> Russ. >> >> On Apr 19, 2012, at 2:20 AM, Andrey Ivanov wrote: >> >>> Hi Russel, >>> >>> >>> Le 18 avril 2012 23:06, Russell Beall <[email protected]> a écrit : >>> On Apr 18, 2012, at 11:15 AM, Rich Megginson wrote: >>>> Yeah, this particular operation has not been optimized. I believe SunDS >>>> added explicit optimizations for this particular case. >>> >>> >>> It is becoming painfully apparent as I write more detailed tests. 389 >>> takes time to add or delete uniquemember values proportionate to the number >>> of values being operated on and is using about twice as much time to delete >>> as it does to add. Sun DS appears to have perhaps an almost O(1) algorithm >>> in play on both adding and deleting values. >>> >>> Is there perhaps some kind of referential integrity setting that is being >>> used and forcing some kind of lookup of each value, one that we could >>> perhaps turn off? We wouldn't need such a check because our metadirectory >>> process handles the integrity/consistency checking already. >>> >>> There is memberOf plugin that maintains the memberOf attribute for groups. >>> I don't know whether it is activated by default or not. You could try to >>> disable it. There is also referential integrity plugin, attribute >>> uniqueness plugin, maybe USN plugin or custom indexes that could consume a >>> lot of CPU. Make sure you've disabled them if you don't need them. >>> >>> @+ >>> -- >>> 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
