I actually added multi-threading code to slapadd in a previous experiment. It's probably still in CVS, but I removed the code because it yielded no measurable improvement. I think the problem is that this will be I/O bound regardless of what CPU resources are available.I haven't investigated this issue yet but would exploiting multiple CPUs allow faster slapadds (with -q, i.e. with less consistency checks) if, for instance, the entry and the indices are generated concurrently? Much like the ancient ldif2index. This comes from the consideration that on the machine we're testing giant slapadds, we have 75% to 87.5% of the CPU idle...
Does anybody see any big stopper to this approach?
-- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/