[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: ldapadd performance
Revisiting this email with a new set of numbers, back-bdb with transactions
completely turned off:
back-bdb
10000 entries
slapd 54.410u 7.210s 8:51.04 11.6% 0+0k 0+0io 1372pf+0w
ldadd 6.730u 1.580s 8:38.74 1.4% 0+0k 0+0io 261pf+0w
The CPU utilization is not much different (11.6%) than the transaction case,
even though the run time is much faster. This seems to imply that if you can
set up the database with the transaction log on a separate physical volume,
there should be much less performance cost for transactions. (Of course, my
test machine has only one disk. Anyone care to experiment with this?)
> -----Original Message-----
> From: Howard Chu [mailto:hyc@highlandsun.com]
> Sent: Monday, November 05, 2001 12:08 AM
> Here are some times running ldapadd against slapd on a PII-400 Linux box,
> adding thousands of entries. The machine has 256M RAM and no
> swapping has occurred on the system thus far.
> back-ldbm dbnosync
> 10000 entries
> slapd 236.250u 102.900s 11:29.12 49.2% 0+0k 0+0io 4866pf+0w
> ldadd 6.560u 1.090s 9:05.58 1.4% 0+0k 0+0io 2044pf+0w
> back-bdb dbnosync
> 10000 entries
> slapd 77.710u 46.730s 17:43.35 11.7% 0+0k 0+0io 2292pf+0w
> ldadd 6.660u 1.490s 14:30.48 0.9% 0+0k 0+0io 2131pf+0w
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support