Re: slapadd performance degradation from 2.3.43 to 2.4.12

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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...

-- 
Hallvard