stasis/je-7.5.11/docs/java/com/sleepycat/je/util/DbCacheSize.html
2019-06-25 16:12:40 -04:00

674 lines
34 KiB
HTML

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!-- NewPage -->
<html lang="en">
<head>
<!-- Generated by javadoc (1.8.0_151) on Tue Oct 31 17:36:46 EDT 2017 -->
<title>DbCacheSize (Oracle - Berkeley DB Java Edition API)</title>
<meta name="date" content="2017-10-31">
<link rel="stylesheet" type="text/css" href="../../../../style.css" title="Style">
<script type="text/javascript" src="../../../../script.js"></script>
</head>
<body>
<script type="text/javascript"><!--
try {
if (location.href.indexOf('is-external=true') == -1) {
parent.document.title="DbCacheSize (Oracle - Berkeley DB Java Edition API)";
}
}
catch(err) {
}
//-->
var methods = {"i0":9};
var tabs = {65535:["t0","All Methods"],1:["t1","Static Methods"],8:["t4","Concrete Methods"]};
var altColor = "altColor";
var rowColor = "rowColor";
var tableTab = "tableTab";
var activeTableTab = "activeTableTab";
</script>
<noscript>
<div>JavaScript is disabled on your browser.</div>
</noscript>
<!-- ========= START OF TOP NAVBAR ======= -->
<div class="topNav"><a name="navbar.top">
<!-- -->
</a>
<div class="skipNav"><a href="#skip.navbar.top" title="Skip navigation links">Skip navigation links</a></div>
<a name="navbar.top.firstrow">
<!-- -->
</a>
<ul class="navList" title="Navigation">
<li><a href="../../../../overview-summary.html">Overview</a></li>
<li><a href="package-summary.html">Package</a></li>
<li class="navBarCell1Rev">Class</li>
<li><a href="class-use/DbCacheSize.html">Use</a></li>
<li><a href="package-tree.html">Tree</a></li>
<li><a href="../../../../deprecated-list.html">Deprecated</a></li>
<li><a href="../../../../index-all.html">Index</a></li>
<li><a href="../../../../help-doc.html">Help</a></li>
</ul>
<div class="aboutLanguage"><b>Berkeley DB Java Edition</b><br><font size=\"-1\"> version 7.5.11</font>
</div>
</div>
<div class="subNav">
<ul class="navList">
<li><a href="../../../../com/sleepycat/je/util/DbBackup.html" title="class in com.sleepycat.je.util"><span class="typeNameLink">Prev&nbsp;Class</span></a></li>
<li><a href="../../../../com/sleepycat/je/util/DbDeleteReservedFiles.html" title="class in com.sleepycat.je.util"><span class="typeNameLink">Next&nbsp;Class</span></a></li>
</ul>
<ul class="navList">
<li><a href="../../../../index.html?com/sleepycat/je/util/DbCacheSize.html" target="_top">Frames</a></li>
<li><a href="DbCacheSize.html" target="_top">No&nbsp;Frames</a></li>
</ul>
<ul class="navList" id="allclasses_navbar_top">
<li><a href="../../../../allclasses-noframe.html">All&nbsp;Classes</a></li>
</ul>
<div>
<script type="text/javascript"><!--
allClassesLink = document.getElementById("allclasses_navbar_top");
if(window==top) {
allClassesLink.style.display = "block";
}
else {
allClassesLink.style.display = "none";
}
//-->
</script>
</div>
<div>
<ul class="subNavList">
<li>Summary:&nbsp;</li>
<li>Nested&nbsp;|&nbsp;</li>
<li>Field&nbsp;|&nbsp;</li>
<li>Constr&nbsp;|&nbsp;</li>
<li><a href="#method.summary">Method</a></li>
</ul>
<ul class="subNavList">
<li>Detail:&nbsp;</li>
<li>Field&nbsp;|&nbsp;</li>
<li>Constr&nbsp;|&nbsp;</li>
<li><a href="#method.detail">Method</a></li>
</ul>
</div>
<a name="skip.navbar.top">
<!-- -->
</a></div>
<!-- ========= END OF TOP NAVBAR ========= -->
<!-- ======== START OF CLASS DATA ======== -->
<div class="header">
<div class="subTitle">com.sleepycat.je.util</div>
<h2 title="Class DbCacheSize" class="title">Class DbCacheSize</h2>
</div>
<div class="contentContainer">
<ul class="inheritance">
<li>java.lang.Object</li>
<li>
<ul class="inheritance">
<li>com.sleepycat.je.util.DbCacheSize</li>
</ul>
</li>
</ul>
<div class="description">
<ul class="blockList">
<li class="blockList">
<hr>
<br>
<pre>public class <span class="typeNameLabel">DbCacheSize</span>
extends java.lang.Object</pre>
<div class="block">Estimates the in-memory cache size needed to hold a specified data set.
To get an estimate of the in-memory footprint for a given database,
specify the number of records and database characteristics and DbCacheSize
will return an estimate of the cache size required for holding the
database in memory. Based on this information a JE main cache size can be
chosen and then configured using <a href="../../../../com/sleepycat/je/EnvironmentMutableConfig.html#setCacheSize-long-"><code>EnvironmentMutableConfig.setCacheSize(long)</code></a> or
using the <a href="../../../../com/sleepycat/je/EnvironmentConfig.html#MAX_MEMORY"><code>EnvironmentConfig.MAX_MEMORY</code></a> property. An off-heap cache
may also be optionally configured using <a href="../../../../com/sleepycat/je/EnvironmentMutableConfig.html#setOffHeapCacheSize-long-"><code>EnvironmentMutableConfig.setOffHeapCacheSize(long)</code></a> or using the <a href="../../../../com/sleepycat/je/EnvironmentConfig.html#MAX_OFF_HEAP_MEMORY"><code>EnvironmentConfig.MAX_OFF_HEAP_MEMORY</code></a> property.
<h4>Importance of the JE Cache</h4>
The JE cache is not an optional cache. It is used to hold the metadata for
accessing JE data. In fact the JE cache size is probably the most critical
factor to JE performance, since Btree nodes will have to be fetched during a
database read or write operation if they are not in cache. During a single
read or write operation, at each level of the Btree that a fetch is
necessary, an IO may be necessary at a different disk location for each
fetch. In addition, if internal nodes (INs) are not in cache, then write
operations will cause additional copies of the INs to be written to storage,
as modified INs are moved out of the cache to make room for other parts of
the Btree during subsequent operations. This additional fetching and
writing means that sizing the cache too small to hold the INs will result in
lower operation performance.
<p>
For best performance, all Btree nodes should fit in the JE cache, including
leaf nodes (LNs), which hold the record data, and INs, which hold record
keys and other metadata. However, because system memory is limited, it is
sometimes necessary to size the cache to hold all or at least most INs, but
not the LNs. This utility estimates the size necessary to hold only INs,
and the size to hold INs and LNs.
<p>
In addition, a common problem with large caches is that Java GC overhead
can become significant. When a Btree node is evicted from the JE main
cache based on JE's LRU algorithm, typically the node will have been
resident in the JVM heap for an extended period of time, and will be
expensive to GC. Therefore, when most or all LNs do <em>not</em> fit in
the main cache, using <a href="../../../../com/sleepycat/je/CacheMode.html#EVICT_LN"><code>CacheMode.EVICT_LN</code></a> can be beneficial to
reduce the Java GC cost of collecting the LNs as they are moved out of the
main cache. With EVICT_LN, the LNs only reside in the JVM heap for a short
period and are cheap to collect. A recommended approach is to size the JE
main cache to hold only INs, and size the Java heap to hold that amount plus
the amount needed for GC working space and application objects, leaving
any additional memory for use by the file system cache or the off-heap
cache. Tests show this approach results in lower GC overhead and more
predictable latency.
<p>
Another issue is that 64-bit JVMs store object references using less space
when the heap size is slightly less than 32GiB. When the heap size is 32GiB
or more, object references are larger and less data can be cached per GiB of
memory. This JVM feature is enabled with the
<a href="http://download.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#compressedOop">Compressed Oops</a>
(<code>-XX:+UseCompressedOops</code>) option, although in modern JVMs it is
on by default. Because of this factor, and because Java GC overhead is
usually higher with larger heaps, a maximum heap size slightly less than
32GiB is recommended, along with Compressed Oops option.
<p>
Of course, the JE main cache size must be less than the heap size since the
main cache is stored in the heap. In fact, around 30% of free space should
normally be reserved in the heap for use by Java GC, to avoid high GC
overheads. For example, if the application uses roughly 2GiB of the heap,
then with a 32GiB heap the JE main cache should normally be no more than
20GiB.
<p>
As of JE 6.4, an optional off-heap cache may be configured in addition to
the main JE cache. See <a href="../../../../com/sleepycat/je/EnvironmentMutableConfig.html#setOffHeapCacheSize-long-"><code>EnvironmentMutableConfig.setOffHeapCacheSize(long)</code></a> for
information about the trade-offs in using an off-heap cache. When the
<code>-offheap</code> argument is specified, this utility displays sizing
information for both the main and off-heap caches. The portion of the data
set that fits in the main cache, and the off-heap size needed to hold the
rest of the data set, will be shown. The main cache size can be specified
with the <code>-maincache</code> argument, or is implied to be the amount needed
to hold all internal nodes if this argument is omitted. Omitting this
argument is appropriate when <a href="../../../../com/sleepycat/je/CacheMode.html#EVICT_LN"><code>CacheMode.EVICT_LN</code></a> is used, since only
internal nodes will be stored in the main cache.
<p>
To reduce Java GC overhead, sometimes a small main cache is used along
with an off-heap cache. Note that it is important that the size the main
cache is at least large enough to hold all the upper INs (the INs at level
2 and above). This is because the off-heap cache does not contain upper
INs, it only contains LNs and bottom internal nodes (BINs). When a level 2
IN is evicted from the main cache, its children (BINs and LNs) in the
off-heap cache, if any, must also be evicted, which can be undesirable,
especially if the off-heap cache is not full. This utility displays the
main cache size needed to hold all upper INs, and displays a warning if
this is smaller than the main cache size specified.
<h4>Estimating the JE Cache Size</h4>
Estimating JE in-memory sizes is not straightforward for several reasons.
There is some fixed overhead for each Btree internal node, so fanout
(maximum number of child entries per parent node) and degree of node
sparseness impacts memory consumption. In addition, JE uses various compact
in-memory representations that depend on key sizes, data sizes, key
prefixing, how many child nodes are resident, etc. The physical proximity
of node children also allows compaction of child physical address values.
<p>
Therefore, when running this utility it is important to specify all <a href="../../../../com/sleepycat/je/EnvironmentConfig.html" title="class in com.sleepycat.je"><code>EnvironmentConfig</code></a> and <a href="../../../../com/sleepycat/je/DatabaseConfig.html" title="class in com.sleepycat.je"><code>DatabaseConfig</code></a> settings that will be used in
a production system. The <a href="../../../../com/sleepycat/je/EnvironmentConfig.html" title="class in com.sleepycat.je"><code>EnvironmentConfig</code></a> settings are specified
by command line options for each property, using the same names as the
<a href="../../../../com/sleepycat/je/EnvironmentConfig.html" title="class in com.sleepycat.je"><code>EnvironmentConfig</code></a> parameter name values. For example, <a href="../../../../com/sleepycat/je/EnvironmentConfig.html#LOG_FILE_MAX"><code>EnvironmentConfig.LOG_FILE_MAX</code></a>, which influences the amount of memory used
to store physical record addresses, can be specified on the command line as:
<p>
<code>-je.log.fileMax LENGTH</code>
<p>
To be sure that this utility takes into account all relevant settings,
especially as the utility is enhanced in future versions, it is best to
specify all <a href="../../../../com/sleepycat/je/EnvironmentConfig.html" title="class in com.sleepycat.je"><code>EnvironmentConfig</code></a> settings used by the application.
<p>
The <a href="../../../../com/sleepycat/je/DatabaseConfig.html" title="class in com.sleepycat.je"><code>DatabaseConfig</code></a> settings are specified using command line options
defined by this utility.
<ul>
<li><code>-nodemax ENTRIES</code> corresponds to <a href="../../../../com/sleepycat/je/DatabaseConfig.html#setNodeMaxEntries-int-"><code>DatabaseConfig.setNodeMaxEntries(int)</code></a>.</li>
<li><code>-duplicates</code> corresponds to passing true to <a href="../../../../com/sleepycat/je/DatabaseConfig.html#setSortedDuplicates-boolean-"><code>DatabaseConfig.setSortedDuplicates(boolean)</code></a>. Note that duplicates are configured
for DPL MANY_TO_ONE and MANY_TO_MANY secondary indices.</li>
<li><code>-keyprefix LENGTH</code> corresponds to passing true <a href="../../../../com/sleepycat/je/DatabaseConfig.html#setKeyPrefixing-boolean-"><code>DatabaseConfig.setKeyPrefixing(boolean)</code></a>. Note that key prefixing is always used
when duplicates are configured.</li>
</ul>
<p>
This utility estimates the JE cache size by creating an in-memory
Environment and Database. In addition to the size of the Database, the
minimum overhead for the Environment is output. The Environment overhead
shown is likely to be smaller than actually needed because it doesn't take
into account use of memory by JE daemon threads (cleaner, checkpointer, etc)
the memory used for locks that are held by application operations and
transactions, the memory for HA network connections, etc. An additional
amount should be added to account for these factors.
<p>
This utility estimates the cache size for a single JE Database, or a logical
table spread across multiple databases (as in the case of Oracle NoSQL DB,
for example). To estimate the size for multiple databases/tables with
different configuration parameters or different key and data sizes, run
this utility for each database/table and sum the sizes. If you are summing
multiple runs for multiple databases/tables that are opened in a single
Environment, the overhead size for the Environment should only be added once.
<p>
In some applications with databases/tables having variable key and data
sizes, it may be difficult to determine the key and data size input
parameters for this utility. If a representative data set can be created,
one approach is to use the <a href="../../../../com/sleepycat/je/util/DbPrintLog.html" title="class in com.sleepycat.je.util"><code>DbPrintLog</code></a> utility with the <code>-S</code>
option to find the average key and data size for all databases/tables, and
use these values as input parameters, as if there were only a single
database/tables. With this approach, it is important that the <code>DatabaseConfig</code> parameters are the same, or at least similar, for all
databases/tables.
<h4>Key Prefixing and Compaction</h4>
Key prefixing deserves special consideration. It can significantly reduce
the size of the cache and is generally recommended; however, the benefit can
be difficult to predict. Key prefixing, in turn, impacts the benefits of
key compaction, and the use of the <a href="../../../../com/sleepycat/je/EnvironmentConfig.html#TREE_COMPACT_MAX_KEY_LENGTH"><code>EnvironmentConfig.TREE_COMPACT_MAX_KEY_LENGTH</code></a> parameter.
<p>
For a given data set, the impact of key prefixing is determined by how many
leading bytes are in common for the keys in a single bottom internal node
(BIN). For example, if keys are assigned sequentially as long (8 byte)
integers, and the <a href="../../../../com/sleepycat/je/DatabaseConfig.html#setNodeMaxEntries-int-"><code>maximum entries
per node</code></a> is 128 (the default value) then 6 or 7 of the 8 bytes of the key
will have a common prefix in each BIN. Of course, when records are deleted,
the number of prefixed bytes may be reduced because the range of key values
in a BIN will be larger. For this example we will assume that, on average,
5 bytes in each BIN are a common prefix leaving 3 bytes per key that are
unprefixed.
<p>
Key compaction is applied when the number of unprefixed bytes is less than a
configured value; see <a href="../../../../com/sleepycat/je/EnvironmentConfig.html#TREE_COMPACT_MAX_KEY_LENGTH"><code>EnvironmentConfig.TREE_COMPACT_MAX_KEY_LENGTH</code></a>.
In the example, the 3 unprefixed bytes per key is less than the default used
for key compaction (16 bytes). This means that each key will use 16 bytes
of memory, in addition to the amount used for the prefix for each BIN. The
per-key overhead could be reduced by changing the <code>TREE_COMPACT_MAX_KEY_LENGTH</code> parameter to a smaller value, but care should
be taken to ensure the compaction will be effective as keys are inserted and
deleted over time.
<p>
Because key prefixing depends so much on the application key format and the
way keys are assigned, the number of expected prefix bytes must be estimated
by the user and specified to DbCacheSize using the <code>-keyprefix</code>
argument.
<h4>Key Prefixing and Duplicates</h4>
When <a href="../../../../com/sleepycat/je/DatabaseConfig.html#setSortedDuplicates-boolean-"><code>duplicates</code></a> are configured
for a Database (including DPL MANY_TO_ONE and MANY_TO_MANY secondary
indices), key prefixing is always used. This is because the internal key in
a duplicates database BIN is formed by concatenating the user-specified key
and data. In secondary databases with duplicates configured, the data is
the primary key, so the internal key is the concatenation of the secondary
key and the primary key.
<p>
Key prefixing is always used for duplicates databases because prefixing is
necessary to store keys efficiently. When the number of duplicates per
unique user-specified key is more than the number of entries per BIN, the
entire user-specified key will be the common prefix.
<p>
For example, a database that stores user information may use email address
as the primary key and zip code as a secondary key. The secondary index
database will be a duplicates database, and the internal key stored in the
BINs will be a two part key containing zip code followed by email address.
If on average there are more users per zip code than the number of entries
in a BIN, then the key prefix will normally be at least as long as the zip
code key. If there are less (more than one zip code appears in each BIN),
then the prefix will be shorter than the zip code key.
<p>
It is also possible for the key prefix to be larger than the secondary key.
If for one secondary key value (one zip code) there are a large number of
primary keys (email addresses), then a single BIN may contain concatenated
keys that all have the same secondary key (same zip code) and have primary
keys (email addresses) that all have some number of prefix bytes in common.
Therefore, when duplicates are specified it is possible to specify a prefix
size that is larger than the key size.
<h4>Small Data Sizes and Embedded LNs</h4>
Another special data representation involves small data sizes. When the
data size of a record is less than or equal to <a href="../../../../com/sleepycat/je/EnvironmentConfig.html#TREE_MAX_EMBEDDED_LN"><code>EnvironmentConfig.TREE_MAX_EMBEDDED_LN</code></a> (16 bytes, by default), the data
is stored (embedded) in the BIN, and the LN is not stored in cache at all.
This increases the size needed to hold all INs in cache, but it decreases
the size needed to hold the complete data set. If the data size specified
when running this utility is less than or equal to TREE_MAX_EMBEDDED_LN,
the size displayed for holding INs only will be the same as the size
displayed for holdings INs and LNs.
<p>
See <a href="../../../../com/sleepycat/je/EnvironmentConfig.html#TREE_MAX_EMBEDDED_LN"><code>EnvironmentConfig.TREE_MAX_EMBEDDED_LN</code></a> for information about
the trade-offs in using the embedded LNs feature.
<h4>Record Versions and Oracle NoSQL Database</h4>
This note applies only to when JE is used with Oracle NoSQL DB. In Oracle
NoSQL DB, an internal JE environment configuration parameter is always
used: <code>-je.rep.preserveRecordVersion true</code>. This allows using record
versions in operations such as "put if version", "delete if version", etc.
This feature performs best when the cache is sized large enough to hold the
record versions.
<p>
When using JE with Oracle NoSQL DB, always add <code>-je.rep.preserveRecordVersion true</code> to the command line. This ensures that
the cache sizes calculated are correct, and also outputs an additional line
showing how much memory is required to hold the internal nodes and record
versions (but not the leaf nodes). This is the minimum recommended size
when the "... if version" operations are used.
<h4>Running the DbCacheSize utility</h4>
Usage:
<pre>
java { com.sleepycat.je.util.DbCacheSize |
-jar je-&lt;version&gt;.jar DbCacheSize }
-records COUNT
# Total records (key/data pairs); required
-key BYTES
# Average key bytes per record; required
[-data BYTES]
# Average data bytes per record; if omitted no leaf
# node sizes are included in the output; required with
# -duplicates, and specifies the primary key length
[-offheap]
# Indicates that an off-heap cache will be used.
[-maincache BYTES]
# The size of the main cache (in the JVM heap).
# The size of the off-heap cache displayed is the
# additional amount needed to hold the data set.
# If omitted, the main cache size is implied to
# be the amount needed to hold all internal nodes.
# Ignored if -offheap is not also specified.
[-keyprefix BYTES]
# Expected size of the prefix for the keys in each
# BIN; default: key prefixing is not configured;
# required with -duplicates
[-nodemax ENTRIES]
# Number of entries per Btree node; default: 128
[-orderedinsertion]
# Assume ordered insertions and no deletions, so BINs
# are 100% full; default: unordered insertions and/or
# deletions, BINs are 70% full
[-duplicates]
# Indicates that sorted duplicates are used, including
# MANY_TO_ONE and MANY_TO_MANY secondary indices;
# default: false
[-ttl]
# Indicates that TTL is used; default: false
[-replicated]
# Use a ReplicatedEnvironment; default: false
[-ENV_PARAM_NAME VALUE]...
# Any number of EnvironmentConfig parameters and
# ReplicationConfig parameters (if -replicated)
[-btreeinfo]
# Outputs additional Btree information
[-outputproperties]
# Writes Java properties file to System.out
</pre>
<p>
You should run DbCacheSize on the same target platform and JVM for which you
are sizing the cache, as cache sizes will vary. You may also need to
specify -d32 or -d64 depending on your target, if the default JVM mode is
not the same as the mode to be used in production.
<p>
To take full advantage of JE cache memory, it is strongly recommended that
<a href="http://download.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#compressedOop">compressed oops</a>
(<code>-XX:+UseCompressedOops</code>) is specified when a 64-bit JVM is used
and the maximum heap size is less than 32 GB. As described in the
referenced documentation, compressed oops is sometimes the default JVM mode
even when it is not explicitly specified in the Java command. However, if
compressed oops is desired then it <em>must</em> be explicitly specified in
the Java command when running DbCacheSize or a JE application. If it is not
explicitly specified then JE will not aware of it, even if it is the JVM
default setting, and will not take it into account when calculating cache
memory sizes.
<p>
For example:
<pre>
$ java -jar je-X.Y.Z.jar DbCacheSize -records 554719 -key 16 -data 100
=== Environment Cache Overhead ===
3,157,213 minimum bytes
To account for JE daemon operation, record locks, HA network connections, etc,
a larger amount is needed in practice.
=== Database Cache Size ===
Number of Bytes Description
--------------- -----------
23,933,736 Internal nodes only
107,206,616 Internal nodes and leaf nodes
</pre>
<p>
This indicates that the minimum memory size to hold only the internal nodes
of the Database Btree is approximately 24MB. The maximum size to hold the
entire database, both internal nodes and data records, is approximately
107MB. To either of these amounts, at least 3MB (plus more for locks and
daemons) should be added to account for the environment overhead.
<p>
The following example adds the use of an off-heap cache, where the main
cache size is specified to be 30MB.
<pre>
$ java -jar je-X.Y.Z.jar DbCacheSize -records 554719 -key 16 -data 100 \
-offheap -maincache 30000000
=== Environment Cache Overhead ===
5,205,309 minimum bytes
To account for JE daemon operation, record locks, HA network connections, etc,
a larger amount is needed in practice.
=== Database Cache Size ===
Number of Bytes Description
--------------- -----------
23,933,736 Internal nodes only: MAIN cache
0 Internal nodes only: OFF-HEAP cache
24,794,691 Internal nodes and leaf nodes: MAIN cache
70,463,604 Internal nodes and leaf nodes: OFF-HEAP cache
</pre>
There are several things of interest in the output.
<ul>
<li>The environment overhead is larger because of memory used for the
off-heap LRU.</li>
<li>To cache only internal nodes, an off-heap cache is not needed since
the internal nodes take around 24MB, which when added to the 5MB
overhead is less than the 30MB main cache specified. This is why the
number of bytes on the second line is zero.</li>
<li>To cache all nodes, the main cache size specified should be used
(25MB added to the 5MB overhead is 30MB), and an off-heap cache of
around 71MB should be configured.</li>
</ul>
<h4>Output Properties</h4>
<p>
When <code>-outputproperties</code> is specified, a list of properties in Java
properties file format will be written to System.out, instead of the output
shown above. The properties and their meanings are listed below.
<ul>
<li>The following properties are always output (except allNodes, see
below). They describe the estimated size of the main cache.
<ul>
<li><strong>overhead</strong>: The environment overhead, as shown
under Environment Cache Overhead above.</li>
<li><strong>internalNodes</strong>: The Btree size in the main
cache for holding the internal nodes. This is the "Internal nodes
only" line above (followed by "MAIN cache" when <code>-offheap</code> is
specified).</li>
<li><strong>internalNodesAndVersions</strong>: The Btree size needed
to hold the internal nodes and record versions in the main cache.
This value is zero when <code>-offheap</code> is specified; currently JE
does not cache record versions off-heap unless their associated LNs
are also cached off-heap, so there is no way to calculate this
property.</li>
<li><strong>allNodes</strong>: The Btree size in the main cache
needed to hold all nodes. This is the "Internal nodes and leaf
nodes" line above (followed by "MAIN cache" when <code>-offheap</code> is
specified). This property is not output unless <code>-data</code> is
specified.</li>
</ul>
<li>The following properties are output only when <code>-offheap</code> is
specified. They describe the estimated size of the off-heap cache.
<ul>
<li><strong>minMainCache</strong>: The minimum size of the main
cache needed to hold all upper INs. When the <code>-maincache</code>
value specified is less than this minimum, not all internal nodes
can be cached. See the discussion further above.</li>
<li><strong>offHeapInternalNodes</strong>: The size of the off-heap
cache needed to hold the internal nodes. This is the "Internal nodes
only: OFF_HEAP cache" line above.</li>
<li><strong>offHeapAllNodes</strong>: The size of the off-heap cache
needed to hold all nodes. This is the "Internal nodes and leaf
nodes: OFF_HEAP cache" line above. This property is not output
unless <code>-data</code> is specified.</li>
</ul>
<li>The following properties are deprecated but are output for
compatibility with earlier releases.
<ul>
<li> minInternalNodes, maxInternalNodes, minAllNodes, and (when
<code>-data</code> is specified) maxAllNodes</li>
</ul>
</ul></div>
<dl>
<dt><span class="seeLabel">See Also:</span></dt>
<dd><a href="../../../../com/sleepycat/je/EnvironmentMutableConfig.html#setCacheSize-long-"><code>EnvironmentMutableConfig.setCacheSize(long)</code></a>,
<a href="../../../../com/sleepycat/je/EnvironmentMutableConfig.html#setOffHeapCacheSize-long-"><code>EnvironmentMutableConfig.setOffHeapCacheSize(long)</code></a>,
<a href="../../../../com/sleepycat/je/CacheMode.html" title="enum in com.sleepycat.je"><code>CacheMode</code></a>,
<a href="../EnvironmentStats.html#cacheSizing">Cache Statistics:
Sizing</a></dd>
</dl>
</li>
</ul>
</div>
<div class="summary">
<ul class="blockList">
<li class="blockList">
<!-- ========== METHOD SUMMARY =========== -->
<ul class="blockList">
<li class="blockList"><a name="method.summary">
<!-- -->
</a>
<h3>Method Summary</h3>
<table class="memberSummary" border="0" cellpadding="3" cellspacing="0" summary="Method Summary table, listing methods, and an explanation">
<caption><span id="t0" class="activeTableTab"><span>All Methods</span><span class="tabEnd">&nbsp;</span></span><span id="t1" class="tableTab"><span><a href="javascript:show(1);">Static Methods</a></span><span class="tabEnd">&nbsp;</span></span><span id="t4" class="tableTab"><span><a href="javascript:show(8);">Concrete Methods</a></span><span class="tabEnd">&nbsp;</span></span></caption>
<tr>
<th class="colFirst" scope="col">Modifier and Type</th>
<th class="colLast" scope="col">Method and Description</th>
</tr>
<tr id="i0" class="altColor">
<td class="colFirst"><code>static void</code></td>
<td class="colLast"><code><span class="memberNameLink"><a href="../../../../com/sleepycat/je/util/DbCacheSize.html#main-java.lang.String:A-">main</a></span>(java.lang.String[]&nbsp;args)</code>
<div class="block">Runs DbCacheSize as a command line utility.</div>
</td>
</tr>
</table>
<ul class="blockList">
<li class="blockList"><a name="methods.inherited.from.class.java.lang.Object">
<!-- -->
</a>
<h3>Methods inherited from class&nbsp;java.lang.Object</h3>
<code>clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait</code></li>
</ul>
</li>
</ul>
</li>
</ul>
</div>
<div class="details">
<ul class="blockList">
<li class="blockList">
<!-- ============ METHOD DETAIL ========== -->
<ul class="blockList">
<li class="blockList"><a name="method.detail">
<!-- -->
</a>
<h3>Method Detail</h3>
<a name="main-java.lang.String:A-">
<!-- -->
</a>
<ul class="blockListLast">
<li class="blockList">
<h4>main</h4>
<pre>public static&nbsp;void&nbsp;main(java.lang.String[]&nbsp;args)
throws java.lang.Throwable</pre>
<div class="block">Runs DbCacheSize as a command line utility.
For command usage, see <a href="../../../../com/sleepycat/je/util/DbCacheSize.html" title="class in com.sleepycat.je.util"><code>class description</code></a>.</div>
<dl>
<dt><span class="throwsLabel">Throws:</span></dt>
<dd><code>java.lang.Throwable</code></dd>
</dl>
</li>
</ul>
</li>
</ul>
</li>
</ul>
</div>
</div>
<!-- ========= END OF CLASS DATA ========= -->
<!-- ======= START OF BOTTOM NAVBAR ====== -->
<div class="bottomNav"><a name="navbar.bottom">
<!-- -->
</a>
<div class="skipNav"><a href="#skip.navbar.bottom" title="Skip navigation links">Skip navigation links</a></div>
<a name="navbar.bottom.firstrow">
<!-- -->
</a>
<ul class="navList" title="Navigation">
<li><a href="../../../../overview-summary.html">Overview</a></li>
<li><a href="package-summary.html">Package</a></li>
<li class="navBarCell1Rev">Class</li>
<li><a href="class-use/DbCacheSize.html">Use</a></li>
<li><a href="package-tree.html">Tree</a></li>
<li><a href="../../../../deprecated-list.html">Deprecated</a></li>
<li><a href="../../../../index-all.html">Index</a></li>
<li><a href="../../../../help-doc.html">Help</a></li>
</ul>
<div class="aboutLanguage"><b>Berkeley DB Java Edition</b><br><font size=\"-1\"> version 7.5.11</font>
</div>
</div>
<div class="subNav">
<ul class="navList">
<li><a href="../../../../com/sleepycat/je/util/DbBackup.html" title="class in com.sleepycat.je.util"><span class="typeNameLink">Prev&nbsp;Class</span></a></li>
<li><a href="../../../../com/sleepycat/je/util/DbDeleteReservedFiles.html" title="class in com.sleepycat.je.util"><span class="typeNameLink">Next&nbsp;Class</span></a></li>
</ul>
<ul class="navList">
<li><a href="../../../../index.html?com/sleepycat/je/util/DbCacheSize.html" target="_top">Frames</a></li>
<li><a href="DbCacheSize.html" target="_top">No&nbsp;Frames</a></li>
</ul>
<ul class="navList" id="allclasses_navbar_bottom">
<li><a href="../../../../allclasses-noframe.html">All&nbsp;Classes</a></li>
</ul>
<div>
<script type="text/javascript"><!--
allClassesLink = document.getElementById("allclasses_navbar_bottom");
if(window==top) {
allClassesLink.style.display = "block";
}
else {
allClassesLink.style.display = "none";
}
//-->
</script>
</div>
<div>
<ul class="subNavList">
<li>Summary:&nbsp;</li>
<li>Nested&nbsp;|&nbsp;</li>
<li>Field&nbsp;|&nbsp;</li>
<li>Constr&nbsp;|&nbsp;</li>
<li><a href="#method.summary">Method</a></li>
</ul>
<ul class="subNavList">
<li>Detail:&nbsp;</li>
<li>Field&nbsp;|&nbsp;</li>
<li>Constr&nbsp;|&nbsp;</li>
<li><a href="#method.detail">Method</a></li>
</ul>
</div>
<a name="skip.navbar.bottom">
<!-- -->
</a></div>
<!-- ======== END OF BOTTOM NAVBAR ======= -->
<p class="legalCopy"><small><font size=1>Copyright (c) 2002, 2017 Oracle and/or its affiliates. All rights reserved.</font> </small></p>
</body>
</html>