On Feb 25, 2010, at 9:29 AM, Jeff Johnson wrote: >> >> Deadlock diagnosis is described in chapter 11 here: >> >> >> http://www.oracle.com/technology/documentation/berkeley-db/db/programmer_reference/index.html >> >> The db_stat I captured (I have the full file if interested) showed >> a page self-deadlock: >> >> ... >> 800036f7 WRITE 3 HELD ptree page 1213 >> 2 READ 1 WAIT ptree page 1213 >> ... >> >> which (tenatively) I attribute to either >> 1) a write cursor isn't being closed correctly in pTreeDB.ml >> or (my hunch) >> 2) there's a duplicate key that is stored on the same page >> >> Caveat: these are just very preliminary guesses. I'll dig out a fix >> over the next month while attempting to add DB_INIT_LOCK to pTreeDB.ml. >>
I now have 2 more deadlocks using DB_INIT_LOCK captured with db/recon logs at debuglevel: 10 All that is needed to trigger a deadlock is a moderately large update. Having read more about the incrementally maintained partition tree, what I suspect is happening is that the ripple effect updating checksums is triggering a self deadlock like above. All 3 deadlocks are similar, just on different pages. One easy (if you're an OCAML programmer, alas not me yet) thing to try would be to try adding DB_RMW to the read cursor flags. That should take out a WRITE lock instead and (one hopes) that Berkeley DB will then avoid the deadlock. Another hacky fix would be to reduce the ptree pagesize to the minimum 512b (iirc pagesize is 2Kb but I could be wrong) in order to have finer granularirt. But that won't solve the fundamental problem, just reduce its incidence. Checking ... Nah the pagesize is already at 512b, never mind. $ sudo db47_stat -d ptree Thu Feb 25 13:00:50 2010 Local time 53162 Btree magic number 9 Btree version number Little-endian Byte order Flags 2 Minimum keys per-page 512 Underlying database page size ... Again, there's nothing particularly wrong with not using DB_INIT_LOCK on the PTree database, since it is a single thread of control. hth 73 de Jeff _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel