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. 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
