mirror of
https://github.com/yasuhirokimura/db18
synced 2026-06-08 18:29:23 +00:00
Yasuhiro KIMURA
282 lines
14 KiB
HTML
282 lines
14 KiB
HTML
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
|
||
<title>Memory-only or Flash configurations</title>
|
||
<link rel="stylesheet" href="gettingStarted.css" type="text/css" />
|
||
<meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
|
||
<link rel="start" href="index.html" title="Berkeley DB Programmer's Reference Guide" />
|
||
<link rel="up" href="program.html" title="Chapter 17. Programmer Notes" />
|
||
<link rel="prev" href="program_namespace.html" title="Name spaces" />
|
||
<link rel="next" href="program_cache.html" title="Disk drive caches" />
|
||
</head>
|
||
<body>
|
||
<div xmlns="" class="navheader">
|
||
<div class="libver">
|
||
<p>Library Version 18.1.32</p>
|
||
</div>
|
||
<table width="100%" summary="Navigation header">
|
||
<tr>
|
||
<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 17. Programmer Notes </th>
|
||
<td width="20%" align="right"> <a accesskey="n" href="program_cache.html">Next</a></td>
|
||
</tr>
|
||
</table>
|
||
<hr />
|
||
</div>
|
||
<div class="sect1" lang="en" xml:lang="en">
|
||
<div class="titlepage">
|
||
<div>
|
||
<div>
|
||
<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>
|
||
<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>
|
||
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>
|
||
</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>
|
||
</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>
|
||
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>
|
||
</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>
|
||
<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>
|
||
</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>
|
||
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>
|
||
</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>
|
||
<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>
|
||
</dd>
|
||
</dl>
|
||
</div>
|
||
</div>
|
||
<div class="navfooter">
|
||
<hr />
|
||
<table width="100%" summary="Navigation footer">
|
||
<tr>
|
||
<td width="40%" align="left"><a accesskey="p" href="program_namespace.html">Prev</a> </td>
|
||
<td width="20%" align="center">
|
||
<a accesskey="u" href="program.html">Up</a>
|
||
</td>
|
||
<td width="40%" align="right"> <a accesskey="n" href="program_cache.html">Next</a></td>
|
||
</tr>
|
||
<tr>
|
||
<td width="40%" align="left" valign="top">Name spaces </td>
|
||
<td width="20%" align="center">
|
||
<a accesskey="h" href="index.html">Home</a>
|
||
</td>
|
||
<td width="40%" align="right" valign="top"> Disk drive caches</td>
|
||
</tr>
|
||
</table>
|
||
</div>
|
||
</body>
|
||
</html>
|