Re: Lock tuning

[Howard Chu <hyc@symas.com>]

matthew sporleder wrote:
> After reading
> http://www.oracle.com/technology/documentation/berkeley-db/db/ref/lock/max.html 
>
>
> I started to look at db_stat -c and noticed this:
> 5203    Total number of locks not immediately available due to conflicts.
> 15      Number of deadlocks.

> Any hints as to why I would have deadlocks, or locks not available?
> Maybe I'm misreading what a conflict is vs just contention.

> Thanks,
> _Matt
>
> (.. if only I knew what the conflict matrix was trying to say ;)
> .
All of that is normal. A lock conflict occurs whenever two different threads 
try to lock the same object, using incompatible modes. The conflict matrix 
tells you which modes are compatible. E.g., a read lock is compatible with 
other read locks, but not with a write lock. So if one thread already has a 
write lock on an object, any other thread that tries to get a read lock on 
the same object will conflict. The BDB lock subsystem supports a lot of other 
modes as well, but we don't use them explicitly; they're mainly used 
internally in the BDB library.

Deadlocks are a pretty much unavoidable occurrence when you have multiple 
threads active, obtaining multiple types of locks at the same time. We try to 
acquire resources in a consistent order to minimize them, but there's a lot 
of lock activity happening inside the BDB library that we have no direct 
control over. It's not a big deal; the code retries automatically when a 
deadlock occurs.

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