Berkeley DB Family

We have a system currently using BerkeleyDB 5.1.25 with fairly large databases and associated cache configurations. (Mpool = 1.5 GB, Data Files at about 4GB). During runtime, all transactions proceeded correctly for some time, and then we began receiving the error "Exception in thread "pool-2-thread-1598878" java.lang.OutOfMemoryError: Cannot allocate memory: unable to allocate memory for mutex; resize mutex region". This error then repeats through all subsequent transactions.

When this occurred a check with "db_stat -x" showed the following:

96MB 704KB Mutex region size
19382 The number of region locks that required waiting (0%)
4 Mutex alignment
1200 Mutex test-and-set spins
666981 Mutex total count
1 Mutex free count
666980 Mutex in-use count
666981 Mutex maximum in-use count
Mutex counts
1 Unallocated
5 db handle
1 env dblist
2 env handle
1 env region
243 lock region
6 logical lock
1 log filename
1 log flush
2 log region
5 mpoolfile handle
*404537 mpool buffer*
5 mpool filehandle
17 mpool file bucket
1 mpool handle
262147 mpool hash bucket
1 mpool region
1 mutex region
1 twister
1 txn active list
1 transaction checkpoint
1 txn region

Upon stopping the service, and restarting it, another check of db_stat -x shows many of the same values with the exception of the mutexes being used for the mpool buffer, which has dropped down to about 40k, but is also growing gradually as the system runs.

I am trying to determine how to resolve the issue with the environment running out of mutexes.

From looking at the code, when an environment is created, the mutex region is by default computed to a size which includes some # of mutexes based (I think) on the mpool region size. If the issue here is that I need to increase that value because the computation is not right, how many mutexes do I need for the region? Is there a way that I can compute the maximum number of mutexes needed by the mpool region?

What could be causing the gradual increase in the number of mutexes associated with the mpool buffer? It is accurate to say that the mpool region (cache) is filling with pages from the data region as the system runs, so is this just a question of having to set a higher maximum?