[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: slapadd/slapindex





--On Thursday, October 27, 2005 2:36 PM -0700 Quanah Gibson-Mount <quanah@stanford.edu> wrote:



--On Thursday, October 27, 2005 5:08 AM -0700 Howard Chu <hyc@symas.com>
wrote:

Using two threads (my machine is dual-core) the slapindex -q time is now
only 10 minutes, using a BDB cache of 768MB and no IDL caching. Adding
IDL caching here slows it down to 15 minutes, so I've decided to disable
that bit of code by default.

I've added a new global config parameter "tool-threads" (olcTooThreads)
to control how many threads the indexer will use. The default value is 1.
For multiple threads, all of the attributes that need indexing in an
entry are divided up among each of the threads, so only one entry is in
progress at a time. On my tests there was no advantage to using more
threads than there are processors. More testing would be welcome...

After the fix to libldap_r was applied, using 4 threads for slapadd on my 4 CPU box resulted in:

ldap-dev1:/tmp/db# time slapadd -q -l dev1-db
[########################################] (100%) 01h25m   367339 obj
10425.20u 2625.06s 1:29:58.64 241.7%

Which is approximately 1 hour less than it took before threaded slapindex
-- A *major* performance improvement.

Time prior to threaded slapadd was 2 hours 25 minutes (just to note where the almost an hour less bit comes in).


--Quanah



--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

"These censorship operations against schools and libraries are stronger
than ever in the present religio-political climate. They often focus on
fantasy and sf books, which foster that deadly enemy to bigotry and blind
faith, the imagination." -- Ursula K. Le Guin