On Apr 18, 2012, at 11:15 AM, Rich Megginson wrote: > You mean, with SunDS? On Linux or Solaris?
The Sun DS instance I'm talking about is on Sun v440 machines. The 389 instance is on relatively new servers with RedHat Linux 6. > 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. This behavior is especially surprising given that I can run ldapdelete on the entry followed by ldapadd and the changes are almost instantaneous. I can delete and then re-add all 852 groups, some with 80K+ unique member attributes, in about ten minutes (using 389). Why would membership changes on the group take forever to process if the entire group can be reconstructed in an instant? Could this operation be optimized internally by turning the ldapmodify into a two-step process of ldapdelete followed by ldapadd (locking the entry during the processing and not actually replicating it that way so the group never appears to be missing)? Thanks, Russ.
-- 389 users mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/389-users
