After reading http://www.oracle.com/technology/documentation/berkeley-db/db/ref/lock/max.h...
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.
Now, these numbers of pretty low compared to all the other stuff with M's at the end, but the following would imply that there's plenty of capacity: 1000 Maximum number of locks possible. 1000 Maximum number of lockers possible. 1000 Maximum number of lock objects possible. 4 Number of current locks. 74 Maximum number of locks at any one time. 59 Number of current lockers. 71 Maximum number of lockers at any one time. 4 Number of current lock objects. 39 Maximum number of lock objects at any one time.
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 ;)
matthew sporleder wrote:
After reading http://www.oracle.com/technology/documentation/berkeley-db/db/ref/lock/max.h...
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.
On 1/3/07, Howard Chu hyc@symas.com wrote:
matthew sporleder wrote:
After reading http://www.oracle.com/technology/documentation/berkeley-db/db/ref/lock/max.h...
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.
Thanks for the re-assurance.
openldap-software@openldap.org
-
Howard Chu -
matthew sporleder