Configuring the memory pool
Prev | Chapter 17. The Memory Pool Subsystem | Next

## Configuring the memory pool

There are two issues to consider when configuring the memory pool.

The first issue, the most important tuning parameter for Berkeley DB applications, is the size of the memory pool. There are two ways to specify the pool size. First, calling the DB_ENV->set_cachesize() method specifies the pool size for all of the applications sharing the Berkeley DB environment. Second, the DB->set_cachesize() method only specifies a pool size for the specific database. Note: It is meaningless to call DB->set_cachesize() for a database opened inside of a Berkeley DB environment because the environment pool size will override any pool size specified for a single database. For information on tuning the Berkeley DB cache size, see Selecting a cache size.

Note the memory pool defaults to assuming that the average page size is 4k. This factor is used to determine the size of the hash table used to locate pages in the memory pool. The size of the hash table is calculated to so that on average 2.5 pages will be in each hash table entry. Each page requires a mutex be allocated to it and the average page size is used to determine the number of mutexes to allocate to the memory pool.

Normally you should see good results by using the default values for the page size, but in some cases you may be able to achieve better performance by manually configuring the page size. The expected page size, hash table size and mutex count can be set via the methods: DB_ENV->set_mp_pagesize(), DB_ENV->set_mp_tablesize(), and DB_ENV->set_mp_mtxcount().

The second memory pool configuration issue is the maximum size an underlying file can be and still be mapped into the process address space (instead of reading the file's pages into the cache). Mapping files into the process address space can result in better performance because available virtual memory is often much larger than the local cache, and page faults are faster than page copying on many systems. However, in the presence of limited virtual memory, it can cause resource starvation; and in the presence of large databases, it can result in immense process sizes. In addition, because of the requirements of the Berkeley DB transactional implementation, only read-only files can be mapped into process memory.

To specify that no files are to be mapped into the process address space, specify the DB_NOMMAP flag to the DB_ENV->set_flags() method. To specify that any individual file should not be mapped into the process address space, specify the DB_NOMMAP flag to the DB_MPOOLFILE->open() interface. To limit the size of files mapped into the process address space, use the DB_ENV->set_mp_mmapsize() method.

Prev | Up | Next
Chapter 17. The Memory Pool Subsystem | Home | Chapter 18. The Transaction Subsystem