[Date Prev][Date Next]
Re: slapadd performance degradation from 2.3.43 to 2.4.12
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...