Library Version 11.2.5.3

Library Version 12.1.6.1

@@ -22,9 +22,7 @@ - +

Prev	Chapter 18. - The Memory Pool Subsystem -	Chapter 18. The Memory Pool Subsystem	Next

@@ -38,52 +36,65 @@

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.

+ 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. +

@@ -96,9 +107,7 @@ the size of files mapped into the process address space, use the Next - Chapter 18. - The Memory Pool Subsystem - + Chapter 18. The Memory Pool Subsystem Home -- cgit v1.2.1