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

Re: slapadd performance degradation from 2.3.43 to 2.4.12

Hallvard B Furuseth wrote:
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.


Right. Perhaps we should remove that mutex lock/unlock.

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.

I guess that's possible; I haven't really looked at BDB's cache replacement policy. I've always assumed it was simple LRU tho frequency-based would be more useful.

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


Good idea.

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


--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/