On svn.collab.net, we're seeing from time to time that Berkeley DB is yielding
"Cannot allocate memory" errors. These don't appear to be actually related to
RAM on the box, nor to the traditional running out of available locks. But
interestingly enough, when no processes are actually using the repository,
db_stat reveals that there are still some outstanding lock items (see below).
This should not be the case. The number of current locks, lockers, and lock
objects, should return to zero after all processes have disconnected from the
repository.
We need to verify that all transactions and cursors are properly closed in both
success and failure cases.
Sample output:
$ /usr/local/BerkeleyDB.4.2/bin/db_stat -c
1539919 Last allocated locker ID.
2147M Current maximum unused locker ID.
9 Number of lock modes.
20000 Maximum number of locks possible.
20000 Maximum number of lockers possible.
20000 Maximum number of lock objects possible.
816 Number of current locks.
881 Maximum number of locks at any one time.
1701 Number of current lockers.
1748 Maximum number of lockers at any one time.
8 Number of current lock objects.
78 Maximum number of lock objects at any one time.
1095M Total number of locks requested.
1095M Total number of locks released.
0 Total number of lock requests failing because DB_LOCK_NOWAIT was set.
432 Total number of locks not immediately available due to conflicts.
23 Number of deadlocks.
0 Lock timeout value.
0 Number of locks that have timed out.
0 Transaction timeout value.
0 Number of transactions that have timed out.
7MB 216KB The size of the lock region..
5736 The number of region locks granted after waiting.
1206M The number of region locks granted without waiting.
Bug
Critical