diff options
Diffstat (limited to 'docs/programmer_reference/program_ram.html')
| -rw-r--r-- | docs/programmer_reference/program_ram.html | 303 |
1 files changed, 169 insertions, 134 deletions
diff --git a/docs/programmer_reference/program_ram.html b/docs/programmer_reference/program_ram.html index f94e863e..698d75b4 100644 --- a/docs/programmer_reference/program_ram.html +++ b/docs/programmer_reference/program_ram.html @@ -14,17 +14,16 @@ <body> <div xmlns="" class="navheader"> <div class="libver"> - <p>Library Version 11.2.5.3</p> + <p>Library Version 12.1.6.1</p> </div> <table width="100%" summary="Navigation header"> <tr> - <th colspan="3" align="center">Memory-only or Flash configurations</th> + <th colspan="3" align="center">Memory-only or Flash + configurations</th> </tr> <tr> <td width="20%" align="left"><a accesskey="p" href="program_namespace.html">Prev</a> </td> - <th width="60%" align="center">Chapter 15. - Programmer Notes - </th> + <th width="60%" align="center">Chapter 15. Programmer Notes </th> <td width="20%" align="right"> <a accesskey="n" href="program_cache.html">Next</a></td> </tr> </table> @@ -34,191 +33,227 @@ <div class="titlepage"> <div> <div> - <h2 class="title" style="clear: both"><a id="program_ram"></a>Memory-only or Flash configurations</h2> + <h2 class="title" style="clear: both"><a id="program_ram"></a>Memory-only or Flash + configurations</h2> </div> </div> </div> - <p>Berkeley DB supports a variety of memory-based configurations for systems -where filesystem space is either limited in availability or entirely -replaced by some combination of memory and Flash. In addition, Berkeley DB -can be configured to minimize writes to the filesystem when the -filesystem is backed by Flash memory.</p> - <p>There are four parts of the Berkeley DB database environment normally written -to the filesystem: the database environment region files, the database -files, the database environment log files and the replication internal -files. Each of these items can -be configured to live in memory rather than in the filesystem:</p> + <p> + Berkeley DB supports a variety of memory-based + configurations for systems where filesystem space is either + limited in availability or entirely replaced by some + combination of memory and Flash. In addition, Berkeley DB can + be configured to minimize writes to the filesystem when the + filesystem is backed by Flash memory. + </p> + <p> + There are four parts of the Berkeley DB database environment + normally written to the filesystem: the database environment + region files, the database files, the database environment log + files and the replication internal files. Each of these items + can be configured to live in memory rather than in the + filesystem: + </p> <div class="variablelist"> <dl> <dt> <span class="term">The database environment region files:</span> </dt> <dd> + <p> + Each of the Berkeley DB subsystems in a + database environment is described by one or more + regions, or chunks of memory. The regions contain + all of the per-process and per-thread shared + information (including mutexes), that comprise a + Berkeley DB environment. By default, these regions + are backed by the filesystem. In situations where + filesystem backed regions aren't optimal, + applications can create memory-only database + environments in two different types of memory: + either in the application's heap memory or in + system shared memory. + </p> <p> - Each of the Berkeley DB subsystems in a database environment is - described by one or more regions, or chunks of memory. The regions - contain all of the per-process and per-thread shared information - (including mutexes), that comprise a Berkeley DB environment. By - default, these regions are backed by the filesystem. In situations - where filesystem backed regions aren't optimal, applications can - create memory-only database environments in two different types of - memory: either in the application's heap memory or in system shared - memory. - </p> - <p> - To create the database environment in heap memory, specify the - <a href="../api_reference/C/envopen.html#envopen_DB_PRIVATE" class="olink">DB_PRIVATE</a> flag to the <a href="../api_reference/C/envopen.html" class="olink">DB_ENV->open()</a> method. Note that database - environments created in heap memory are only accessible to the - threads of a single process, however. - </p> - <p> - To create the database environment in system shared memory, specify - the <a href="../api_reference/C/envopen.html#envopen_DB_SYSTEM_MEM" class="olink">DB_SYSTEM_MEM</a> flag to the <a href="../api_reference/C/envopen.html" class="olink">DB_ENV->open()</a> method. Database - environments created in system memory are accessible to multiple - processes, but note that database environments created in system - shared memory do create a small (roughly 8 byte) file in the - filesystem, read by the processes to identify which system shared - memory segments to use. - </p> + To create the database environment in heap + memory, specify the <a href="../api_reference/C/envopen.html#envopen_DB_PRIVATE" class="olink">DB_PRIVATE</a> flag to the + <a href="../api_reference/C/envopen.html" class="olink">DB_ENV->open()</a> method. Note that database environments + created in heap memory are only accessible to the + threads of a single process, however. + </p> + <p> + To create the database environment in system + shared memory, specify the <a href="../api_reference/C/envopen.html#envopen_DB_SYSTEM_MEM" class="olink">DB_SYSTEM_MEM</a> flag to + the <a href="../api_reference/C/envopen.html" class="olink">DB_ENV->open()</a> method. Database environments + created in system memory are accessible to + multiple processes, but note that database + environments created in system shared memory do + create a small (roughly 8 byte) file in the + filesystem, read by the processes to identify + which system shared memory segments to use. + </p> <p> - For more information, see <a class="xref" href="env_region.html" title="Shared memory regions">Shared memory regions</a>. - </p> + For more information, see <a class="xref" href="env_region.html" title="Shared memory regions">Shared memory regions</a>. + </p> </dd> <dt> <span class="term">The database files:</span> </dt> <dd> - <p> - By default, databases are periodically flushed from the - Berkeley DB memory cache to backing physical files in the - filesystem. To keep databases from being written to backing - physical files, pass the <a href="../api_reference/C/mempset_flags.html#mpool_set_flags_DB_MPOOL_NOFILE" class="olink">DB_MPOOL_NOFILE</a> flag to the - <a href="../api_reference/C/mempset_flags.html" class="olink">DB_MPOOLFILE->set_flags()</a> method. This flag - implies the application's databases must fit entirely in the - Berkeley DB cache, of course. To avoid a database file growing - to consume the entire cache, applications can limit the size of - individual databases in the cache by calling the - <a href="../api_reference/C/mempset_maxsize.html" class="olink">DB_MPOOLFILE->set_maxsize()</a> method. - </p> + <p> + By default, databases are periodically flushed + from the Berkeley DB memory cache to backing + physical files in the filesystem. To keep + databases from being written to backing physical + files, pass the <a href="../api_reference/C/mempset_flags.html#mpool_set_flags_DB_MPOOL_NOFILE" class="olink">DB_MPOOL_NOFILE</a> flag to the + <a href="../api_reference/C/mempset_flags.html" class="olink">DB_MPOOLFILE->set_flags()</a> method. This flag implies the + application's databases must fit entirely in the + Berkeley DB cache, of course. To avoid a database + file growing to consume the entire cache, + applications can limit the size of individual + databases in the cache by calling the + <a href="../api_reference/C/mempset_maxsize.html" class="olink">DB_MPOOLFILE->set_maxsize()</a> method. + </p> </dd> <dt> <span class="term">The database environment log files:</span> </dt> <dd> + <p> + If a database environment is not intended to be + transactionally recoverable after application or + system failure (that is, if it will not exhibit + the transactional attribute of "durability"), + applications should not configure the database + environment for logging or transactions, in which + case no log files will be created. If the database + environment is intended to be durable, log files + must either be written to stable storage and + recovered after application or system failure, or + they must be replicated to other systems. + </p> <p> - If a database environment is not intended to be transactionally - recoverable after application or system failure (that is, if it - will not exhibit the transactional attribute of "durability"), - applications should not configure the database environment for - logging or transactions, in which case no log files will be - created. If the database environment is intended to be - durable, log files must either be written to stable storage and - recovered after application or system failure, or they must be - replicated to other systems. - </p> - <p> - In applications running on systems without any form of stable - storage, durability must be accomplished through replication. - In this case, database environments should be configured to - maintain database logs in memory, rather than in the - filesystem, by specifying the <a href="../api_reference/C/envlog_set_config.html#log_set_config_DB_LOG_IN_MEMORY" class="olink">DB_LOG_IN_MEMORY</a> flag to the - <a href="../api_reference/C/envlog_set_config.html" class="olink">DB_ENV->log_set_config()</a> method. - </p> + In applications running on systems without any + form of stable storage, durability must be + accomplished through replication. In this case, + database environments should be configured to + maintain database logs in memory, rather than in + the filesystem, by specifying the + <a href="../api_reference/C/envlog_set_config.html#log_set_config_DB_LOG_IN_MEMORY" class="olink">DB_LOG_IN_MEMORY</a> flag to the <a href="../api_reference/C/envlog_set_config.html" class="olink">DB_ENV->log_set_config()</a> + method. + </p> </dd> <dt> <span class="term">The replication internal files:</span> </dt> <dd> <p> - By default, Berkeley DB replication stores a small amount of - internal data in the filesystem. To store this replication - internal data in memory only and not in the filesystem, specify - the <a href="../api_reference/C/repconfig.html#config_DB_REP_CONF_INMEM" class="olink">DB_REP_CONF_INMEM</a> flag to the <a href="../api_reference/C/repconfig.html" class="olink">DB_ENV->rep_set_config()</a> method before - opening the database environment. - </p> + By default, Berkeley DB replication stores a + small amount of internal data in the filesystem. + To store this replication internal data in memory + only and not in the filesystem, specify the + <a href="../api_reference/C/repconfig.html#config_DB_REP_CONF_INMEM" class="olink">DB_REP_CONF_INMEM</a> flag to the <a href="../api_reference/C/repconfig.html" class="olink">DB_ENV->rep_set_config()</a> method + before opening the database environment. + </p> </dd> </dl> </div> - <p>In systems where the filesystem is backed by Flash memory, the number -of times the Flash memory is written may be a concern. Each of the -four parts of the Berkeley DB database environment normally written to the -filesystem can be configured to minimize the number of times the -filesystem is written:</p> + <p> + In systems where the filesystem is backed by Flash memory, + the number of times the Flash memory is written may be a + concern. Each of the four parts of the Berkeley DB database + environment normally written to the filesystem can be + configured to minimize the number of times the filesystem is + written: + </p> <div class="variablelist"> <dl> <dt> <span class="term">The database environment region files:</span> </dt> <dd> - <p> - On a Flash-based filesystem, the database environment should be placed - in heap or system memory, as described previously. - </p> + <p> + On a Flash-based filesystem, the database + environment should be placed in heap or system + memory, as described previously. + </p> </dd> <dt> <span class="term">The database files:</span> </dt> <dd> + <p> + The Berkeley DB library maintains a cache of + database pages. The database pages are only + written to backing physical files when the + application checkpoints the database environment + with the <a href="../api_reference/C/txncheckpoint.html" class="olink">DB_ENV->txn_checkpoint()</a> method, when database + handles are closed with the <a href="../api_reference/C/dbclose.html" class="olink">DB->close()</a> method, or + when the application explicitly flushes the cache + with the <a href="../api_reference/C/dbsync.html" class="olink">DB->sync()</a> or <a href="../api_reference/C/mempsync.html" class="olink">DB_ENV->memp_sync()</a> methods. + </p> <p> - The Berkeley DB library maintains a cache of database pages. - The database pages are only written to backing physical files - when the application checkpoints the database environment with - the <a href="../api_reference/C/txncheckpoint.html" class="olink">DB_ENV->txn_checkpoint()</a> method, when database handles are closed - with the <a href="../api_reference/C/dbclose.html" class="olink">DB->close()</a> method, or when the application explicitly - flushes the cache with the <a href="../api_reference/C/dbsync.html" class="olink">DB->sync()</a> or <a href="../api_reference/C/mempsync.html" class="olink">DB_ENV->memp_sync()</a> methods. - </p> + To avoid unnecessary writes of Flash memory due + to checkpoints, applications should decrease the + frequency of their checkpoints. This is especially + important in applications which repeatedly modify + a specific database page, as repeatedly writing a + database page to the backing physical file will + repeatedly update the same blocks of the + filesystem. + </p> <p> - To avoid unnecessary writes of Flash memory due to checkpoints, - applications should decrease the frequency of their - checkpoints. This is especially important in applications - which repeatedly modify a specific database page, as repeatedly - writing a database page to the backing physical file will - repeatedly update the same blocks of the filesystem. - </p> - <p> - To avoid unnecessary writes of the filesystem due to closing a - database handle, applications should specify the <a href="../api_reference/C/dbclose.html#dbclose_DB_NOSYNC" class="olink">DB_NOSYNC</a> flag - to the <a href="../api_reference/C/dbclose.html" class="olink">DB->close()</a> method. - </p> - <p> - To avoid unnecessary writes of the filesystem due to flushing - the cache, applications should not explicitly flush the cache - under normal conditions – flushing the cache is rarely if - ever needed in a normally-running application. - </p> + To avoid unnecessary writes of the filesystem + due to closing a database handle, applications + should specify the <a href="../api_reference/C/dbclose.html#dbclose_DB_NOSYNC" class="olink">DB_NOSYNC</a> flag to the + <a href="../api_reference/C/dbclose.html" class="olink">DB->close()</a> method. + </p> + <p> + To avoid unnecessary writes of the filesystem + due to flushing the cache, applications should not + explicitly flush the cache under normal conditions + – flushing the cache is rarely if ever + needed in a normally-running application. + </p> </dd> <dt> <span class="term">The database environment log files:</span> </dt> <dd> <p> - The Berkeley DB log files do not repeatedly overwrite the same - blocks of the filesystem as the Berkeley DB log files are not - implemented as a circular buffer and log files are not re-used. - For this reason, the Berkeley DB log files should not cause any - difficulties for Flash memory configurations. - </p> + The Berkeley DB log files do not repeatedly + overwrite the same blocks of the filesystem as the + Berkeley DB log files are not implemented as a + circular buffer and log files are not re-used. For + this reason, the Berkeley DB log files should not + cause any difficulties for Flash memory + configurations. + </p> <p> - However, as Berkeley DB does not write log records in - filesystem block sized pieces, it is probable that sequential - transaction commits (each of which flush the log file to the - backing filesystem), will write a block of Flash memory twice, - as the last log record from the first commit will write the - same block of Flash memory as the first log record from the - second commit. Applications not requiring absolute durability - should specify the <a href="../api_reference/C/envset_flags.html#set_flags_DB_TXN_WRITE_NOSYNC" class="olink">DB_TXN_WRITE_NOSYNC</a> or - <a href="../api_reference/C/envset_flags.html#envset_flags_DB_TXN_NOSYNC" class="olink">DB_TXN_NOSYNC</a> flags to the <a href="../api_reference/C/envset_flags.html" class="olink">DB_ENV->set_flags()</a> - method to avoid this overwrite of a block of Flash memory. - </p> + However, as Berkeley DB does not write log + records in filesystem block sized pieces, it is + probable that sequential transaction commits (each + of which flush the log file to the backing + filesystem), will write a block of Flash memory + twice, as the last log record from the first + commit will write the same block of Flash memory + as the first log record from the second commit. + Applications not requiring absolute durability + should specify the <a href="../api_reference/C/envset_flags.html#set_flags_DB_TXN_WRITE_NOSYNC" class="olink">DB_TXN_WRITE_NOSYNC</a> or + <a href="../api_reference/C/envset_flags.html#envset_flags_DB_TXN_NOSYNC" class="olink">DB_TXN_NOSYNC</a> flags to the <a href="../api_reference/C/envset_flags.html" class="olink">DB_ENV->set_flags()</a> method + to avoid this overwrite of a block of Flash + memory. + </p> </dd> <dt> <span class="term">The replication internal files:</span> </dt> <dd> - <p> - On a Flash-based filesystem, the replication internal data - should be stored in memory only, as described previously. - </p> + <p> + On a Flash-based filesystem, the replication + internal data should be stored in memory only, as + described previously. + </p> </dd> </dl> </div> |