[Date Prev][Date Next]
Re: Lock tuning
matthew sporleder wrote:
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.
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.
(.. if only I knew what the conflict matrix was trying to say ;)
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
-- 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/
- Lock tuning
- From: "matthew sporleder" <email@example.com>