1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
|
<! "@(#)pagesize.so 10.6 (Sleepycat) 11/9/98">
<!Copyright 1997, 1998 by Sleepycat Software, Inc. All rights reserved.>
<html>
<body bgcolor=white>
<head>
<title>Berkeley DB Reference Guide: Access Methods</title>
<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btr
ee,hash,hashing,transaction,transactions,locking,logging,access method,access me
thods,java,C,C++">
</head>
<h3>Berkeley DB Reference Guide: Access Methods</h3>
<p>
<h1 align=center>Selecting a page size</h1>
<p>
The size of the pages used in the underlying database can be specified
as part of the <a href="../../api_c/Db/open.html">db_open</a> call to open the database, specifically
by setting the the <a href="../../api_c/DbInfo/info.html#db_pagesize">db_pagesize</a> element of the DB_INFO
structure.
<p>
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. The selected size has a lower limit of 512 bytes and an
upper limit of 16K bytes.
<p>
There are three issues to consider when selecting a pagesize:
<p>
First, the page size implicitly sets the size of an <b>overflow
record</b>. Overflow records are either key or data items that cannot be
place 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 and/or
modifying overflow records. Selecting a page size that is too small, and
which causes a large number of overflow pages to be created, can seriously
impact the performance of your application.
<p>
Second, Berkeley DB does page-level locking, i.e., access to records in the
database is single-threaded at the granularity of a page, not at the
granularity of a record on the page. Selecting a page size that is too
large, and which causes threads or processes to wait unnecessarily because
other threads of control are accessing or modifying records on the same
page as the waiting thread of control needs to lock can impact the
performance of your application.
<p>
Third, the page size specifies the granularity of I/O from the database
to the operating system (i.e., Berkeley DB will give a page size unit of bytes
to the operating system to be scheduled for writing to the disk). For
most operating systems, there is an internal <b>block size</b> which is
used as the granularity of I/O from the operating system to the disk. If
the page size is smaller than the block size, the operating system may be
forced to read block size bytes from the disk, copy the page size bytes
into the buffer it read, and then write out block size bytes to the disk.
(Obviously, it will be much more efficient for Berkeley DB to write page size
bytes to the operating system and then the operating system to simply
write the same page size bytes to the disk.) So, selecting a page size
that is too small, and which causes the operating system to coalesce or
otherwise manipulate Berkeley DB pages can impact the performance of your
application. Alternatively, selecting a page size that is too large may
cause Berkeley DB and the operating system to write more data than is strictly
necessary.
<p>
<a href="../../ref/am/logrec.html"><img src="../../images/prev.gif"></a>
<a href="../../ref/toc.html"><img src="../../images/toc.gif"></a>
<a href="../../ref/am/cachesize.html"><img src="../../images/next.gif"></a>
</tt>
</body>
</html>
|
