Edit File - File Manager

Edit File: pagesize.html

<html>
<head>
<title>Berkeley DB Reference Guide: Selecting a page size</title>
<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
<meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++">
</head>
<body bgcolor=white>
<a name="2"></a>
<table width="100%"><tr valign=top>
<td><dl><dt>Berkeley DB Reference Guide:<dd>Access Methods</dl></td>
<td align=right><a href="../am_conf/logrec.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../am_conf/cachesize.html"><img src="../../images/next.gif" alt="Next"></a>
</td></tr></table>
Selecting a page size
The size of the pages used in the underlying database can be specified by
calling the <a href="../../api_c/db_set_pagesize.html">DB-&gt;set_pagesize</a> method. The minimum page size is 512 bytes
and the maximum page size is 64K bytes, and must be a power of two. If
no page size is specified by the application, a page size is selected
based on the underlying filesystem I/O block size. (A page size selected
in this way has a lower limit of 512 bytes and an upper limit of 16K
bytes.)
There are several issues to consider when selecting a pagesize: overflow
record sizes, locking, I/O efficiency, and recoverability.
First, the page size implicitly sets the size of an overflow record.
Overflow records are key or data items that are too large to fit on a
normal database page because of their size, and are therefore stored in
overflow pages. Overflow pages are pages that exist outside of the normal
database structure. For this reason, there is often a significant
performance penalty associated with retrieving or modifying overflow
records. Selecting a page size that is too small, and which forces the
creation of large numbers of overflow pages, can seriously impact the
performance of an application.
Second, in the Btree, Hash and Recno access methods, the finest-grained
lock that Berkeley DB acquires is for a page. (The Queue access method
generally acquires record-level locks rather than page-level locks.)
Selecting a page size that is too large, and which causes threads or
processes to wait because other threads of control are accessing or
modifying records on the same page, can impact the performance of your
application.
Third, the page size specifies the granularity of I/O from the database
to the operating system. Berkeley DB will give a page-sized unit of bytes to
the operating system to be scheduled for reading/writing from/to the
disk. For many operating systems, there is an internal block
size which is used as the granularity of I/O from the operating system
to the disk. Generally, it will be more efficient for Berkeley DB to write
filesystem-sized blocks to the operating system and for the operating
system to write those same blocks to the disk.
Selecting a database page size smaller than the filesystem block size
may cause the operating system to coalesce or otherwise manipulate Berkeley DB
pages and can impact the performance of your application. When the page
size is smaller than the filesystem block size and a page written by
Berkeley DB is not found in the operating system's cache, the operating system
may be forced to read a block from the disk, copy the page into the
block it read, and then write out the block to disk, rather than simply
writing the page to disk. Additionally, as the operating system is
reading more data into its buffer cache than is strictly necessary to
satisfy each Berkeley DB request for a page, the operating system buffer cache
may be wasting memory.
Alternatively, selecting a page size larger than the filesystem block
size may cause the operating system to read more data than necessary.
On some systems, reading filesystem blocks sequentially may cause the
operating system to begin performing read-ahead. If requesting a single
database page implies reading enough filesystem blocks to satisfy the
operating system's criteria for read-ahead, the operating system may do
more I/O than is required.
Fourth, when using the Berkeley DB Transactional Data Store product, the page size may affect the errors
from which your database can recover See
<a href="../../ref/transapp/reclimit.html">Berkeley DB Recoverability</a> for more
information.
<table width="100%"><tr><td> </td><td align=right><a href="../am_conf/logrec.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../am_conf/cachesize.html"><img src="../../images/next.gif" alt="Next"></a>
</td></tr></table>
Copyright (c) 1996,2008 Oracle. All rights reserved.
</body>
</html>

Back to File Manager