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

RE: back-bdb deadlocks



> -----Original Message-----
> From: Marijn Meijles [mailto:marijn@bitpit.net]

> You wrote:
> > All of a sudden the lock detector is working on my SuSE 6 system again,
> > but the test takes far too long. With no transactions the test runs in
> > just over a minute. With transactions it takes about 35 minutes on my
> > system. I added a ldap_pvt_thread_yield() after the txn_abort() and that
> > brought the runtime down to 23 minutes. Finally I got sick of it and just
> > decided to serialize the whole thing. As an experiment, I obtained a BDB
> > lock on the parent DN. That brings the test down to 3 minutes, 0 deadlocks.
> What kind of lock and in what database?

Using the Berkeley DB lock_get() function to get a WRITE lock associated with
the transaction. The object being locked is a string, the parent DN. It is not
associated with any particular database. When the transaction commits or aborts
the lock is automatically discarded along with the rest of the transaction.
This would appear to be the only safe way to handle locks in the txn
environment.

> Sure looks like you could use an entry cache ;)

yes....... I believe that's coming soon...

> One more thing, please test harder. Some thread related bugs only show up
> after you have pounded on the damn thing with 50 writers for 2 days or
> so.

I guess if I used 50 writers it would take 2 days at least for one test to
finish.

I've tried several other approaches as well. One that helps is to run the
deadlock detector automatically, (dbenv->set_lk_detect) instead of having a
separate thread do periodic deadlock checks. (When it deadlocks so frequently,
resolving only once every N seconds is much too slow.) In addition, it seems to
help a lot to configure with dbnosync. Not sure why, but the number of
deadlocks drops dramatically then. Also setting the deadlock resolution to
"youngest" instead of default ( =random ) helps. With these settings the test
usually finishes in under a minute.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support