1<!--$Id: pagesize.so,v 10.22 2002/02/11 14:55:53 bostic Exp $--> 2<!--Copyright (c) 1997,2008 Oracle. All rights reserved.--> 3<!--See the file LICENSE for redistribution information.--> 4<html> 5<head> 6<title>Berkeley DB Reference Guide: Selecting a page size</title> 7<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> 8<meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++"> 9</head> 10<body bgcolor=white> 11<a name="2"><!--meow--></a> 12<table width="100%"><tr valign=top> 13<td><b><dl><dt>Berkeley DB Reference Guide:<dd>Access Methods</dl></b></td> 14<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> 15</td></tr></table> 16<p align=center><b>Selecting a page size</b></p> 17<p>The size of the pages used in the underlying database can be specified by 18calling the <a href="/api_c/db_set_pagesize.html">DB->set_pagesize</a> method. The minimum page size is 512 bytes 19and the maximum page size is 64K bytes, and must be a power of two. If 20no page size is specified by the application, a page size is selected 21based on the underlying filesystem I/O block size. (A page size selected 22in this way has a lower limit of 512 bytes and an upper limit of 16K 23bytes.)</p> 24<p>There are several issues to consider when selecting a pagesize: overflow 25record sizes, locking, I/O efficiency, and recoverability.</p> 26<p>First, the page size implicitly sets the size of an overflow record. 27Overflow records are key or data items that are too large to fit on a 28normal database page because of their size, and are therefore stored in 29overflow pages. Overflow pages are pages that exist outside of the normal 30database structure. For this reason, there is often a significant 31performance penalty associated with retrieving or modifying overflow 32records. Selecting a page size that is too small, and which forces the 33creation of large numbers of overflow pages, can seriously impact the 34performance of an application.</p> 35<p>Second, in the Btree, Hash and Recno access methods, the finest-grained 36lock that Berkeley DB acquires is for a page. (The Queue access method 37generally acquires record-level locks rather than page-level locks.) 38Selecting a page size that is too large, and which causes threads or 39processes to wait because other threads of control are accessing or 40modifying records on the same page, can impact the performance of your 41application.</p> 42<p>Third, the page size specifies the granularity of I/O from the database 43to the operating system. Berkeley DB will give a page-sized unit of bytes to 44the operating system to be scheduled for reading/writing from/to the 45disk. For many operating systems, there is an internal <b>block 46size</b> which is used as the granularity of I/O from the operating system 47to the disk. Generally, it will be more efficient for Berkeley DB to write 48filesystem-sized blocks to the operating system and for the operating 49system to write those same blocks to the disk.</p> 50<p>Selecting a database page size smaller than the filesystem block size 51may cause the operating system to coalesce or otherwise manipulate Berkeley DB 52pages and can impact the performance of your application. When the page 53size is smaller than the filesystem block size and a page written by 54Berkeley DB is not found in the operating system's cache, the operating system 55may be forced to read a block from the disk, copy the page into the 56block it read, and then write out the block to disk, rather than simply 57writing the page to disk. Additionally, as the operating system is 58reading more data into its buffer cache than is strictly necessary to 59satisfy each Berkeley DB request for a page, the operating system buffer cache 60may be wasting memory.</p> 61<p>Alternatively, selecting a page size larger than the filesystem block 62size may cause the operating system to read more data than necessary. 63On some systems, reading filesystem blocks sequentially may cause the 64operating system to begin performing read-ahead. If requesting a single 65database page implies reading enough filesystem blocks to satisfy the 66operating system's criteria for read-ahead, the operating system may do 67more I/O than is required.</p> 68<p>Fourth, when using the Berkeley DB Transactional Data Store product, the page size may affect the errors 69from which your database can recover See 70<a href="/ref/transapp/reclimit.html">Berkeley DB Recoverability</a> for more 71information.</p> 72<table width="100%"><tr><td><br></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> 73</td></tr></table> 74<p><font size=1>Copyright (c) 1996,2008 Oracle. All rights reserved.</font> 75</body> 76</html> 77