Re: slapadd performance degradation from 2.3.43 to 2.4.12

[Ralf Haferkamp <rhafer@suse.de>]

Am Montag 24 November 2008 23:47:29 schrieb Hallvard B Furuseth:
> Howard Chu writes:
> > That was to prevent the signal from being lost. Though I suppose it
> > doesn't matter, since the signal would get sent again soon enough.
>
> If it's lost, that'll usually be because memp_trickle() is busily
> flusing pages.  It won't return until it has nothing to do, in
> which case immediately calling it again won't be very useful.
>
>
> A few other thoughts:
>
> Could memp_trickle() have a bug so it loses "page is frequently used"
> info or whatever Berkeley DB is using?  Then it could cause such pages
> to need to be re-read when they'd otherwise not need to be.
>
> The memp_trickle() call the dirty page percentage to 70%.
> Might be interesting to see how a run without the trickle task
> compares to one with trickle + 43% extra DB cache.  (1/0.7 = 1.43).
>
> In the first message, Ralf Haferkamp wrote:
> > I did some profiling (with valgrinds callgrind tool) to find out where
> > all the time is spend and it revealed that 2.4 spend a significantly
> > larger amount of systime in the pwrite() function than 2.3. Most of
> > that seemed to come from the bdb_tool_trickle_task() that calls
> > libdb's memp_trickle() function.
>
> The trickle task takes over write work that is otherwise done from other
> functions.  If it spends as much or more_ time in pwrite() from
> trickle_task() than it does in pwrite() when there is no trickle task,
> that'd be interesting...
As I wrote I compared OpenLDAP 2.3 with 2.4 (both linked against libdb-4.5). 
And libdb-4.5 seems to be buggy with regard to the memp_trickle() function.
I'd need to re-run the profiling with libdb-4.7. Though I am not sure if it is 
really worth it, given improvements when using slapadd with the lock/unlock 
calls removed in bdb_tool_entry_put.

-- 
Ralf