Re: [Sks-devel] Adding DB_INIT_LOCK to sks-keyserver (revisited)

[Jeff Johnson]

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