Sophie

Sophie

distrib > Fedora > 14 > x86_64 > media > updates > by-pkgid > 71d40963b505df4524269198e237b3e3 > files > 870

virtuoso-opensource-doc-6.1.4-2.fc14.noarch.rpm

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
 <head profile="http://internetalchemy.org/2003/02/profile">
  <link rel="foaf" type="application/rdf+xml" title="FOAF" href="http://www.openlinksw.com/dataspace/uda/about.rdf" />
  <link rel="schema.dc" href="http://purl.org/dc/elements/1.1/" />
  <meta name="dc.title" content="19. TPC C Benchmark Kit" />
  <meta name="dc.subject" content="19. TPC C Benchmark Kit" />
  <meta name="dc.creator" content="OpenLink Software Documentation Team ;&#10;" />
  <meta name="dc.copyright" content="OpenLink Software, 1999 - 2009" />
  <link rel="top" href="index.html" title="OpenLink Virtuoso Universal Server: Documentation" />
  <link rel="search" href="/doc/adv_search.vspx" title="Search OpenLink Virtuoso Universal Server: Documentation" />
  <link rel="parent" href="tpcc.html" title="Chapter Contents" />
  <link rel="prev" href="omissionsexcp.html" title="Omissions, Exceptions from the Definition" />
  <link rel="next" href="otherfactors.html" title="Other Factors" />
  <link rel="shortcut icon" href="../images/misc/favicon.ico" type="image/x-icon" />
  <link rel="stylesheet" type="text/css" href="doc.css" />
  <link rel="stylesheet" type="text/css" href="/doc/translation.css" />
  <title>19. TPC C Benchmark Kit</title>
  <meta http-equiv="Content-Type" content="text/xhtml; charset=UTF-8" />
  <meta name="author" content="OpenLink Software Documentation Team ;&#10;" />
  <meta name="copyright" content="OpenLink Software, 1999 - 2009" />
  <meta name="keywords" content="" />
  <meta name="GENERATOR" content="OpenLink XSLT Team" />
 </head>
 <body>
  <div id="header">
    <a name="sampleconf" />
    <img src="../images/misc/logo.jpg" alt="" />
    <h1>19. TPC C Benchmark Kit</h1>
  </div>
  <div id="navbartop">
   <div>
      <a class="link" href="tpcc.html">Chapter Contents</a> | <a class="link" href="omissionsexcp.html" title="Omissions, Exceptions from the Definition">Prev</a> | <a class="link" href="otherfactors.html" title="Other Factors">Next</a>
   </div>
  </div>
  <div id="currenttoc">
   <form method="post" action="/doc/adv_search.vspx">
    <div class="search">Keyword Search: <br />
        <input type="text" name="q" /> <input type="submit" name="go" value="Go" />
    </div>
   </form>
   <div>
      <a href="http://www.openlinksw.com/">www.openlinksw.com</a>
   </div>
   <div>
      <a href="http://docs.openlinksw.com/">docs.openlinksw.com</a>
   </div>
    <br />
   <div>
      <a href="index.html">Book Home</a>
   </div>
    <br />
   <div>
      <a href="contents.html">Contents</a>
   </div>
   <div>
      <a href="preface.html">Preface</a>
   </div>
    <br />
   <div class="selected">
      <a href="tpcc.html">TPC C Benchmark Kit</a>
   </div>
    <br />
   <div>
      <a href="tpcctestdb.html">Building the Test Database</a>
   </div>
   <div>
      <a href="tpccusingtestprg.html">Using the Test Program</a>
   </div>
   <div>
      <a href="tpcctuningparams4users.html">Tuning Parameters and Number of Users</a>
   </div>
   <div>
      <a href="omissionsexcp.html">Omissions, Exceptions from the Definition</a>
   </div>
   <div class="selected">
      <a href="sampleconf.html">Sample Configuration</a>
   </div>
   <div>
      <a href="otherfactors.html">Other Factors</a>
   </div>
   <div>
      <a href="tpccprocs.html">TPC C Procedures</a>
   </div>
   <div>
      <a href="ddlstmt.html">DDL Statements</a>
   </div>
   <div>
      <a href="storedprocs.html">Stored Procedures</a>
   </div>
    <br />
  </div>
  <div id="text">
<a name="sampleconf" />
    <h2>19.5. Sample Configuration</h2>
	<p>
This section describes how to set up disks and I/O for a sample run. 
To begin with, the scaling rule is 12.5 tpmC per warehouse. This
means that in order to measure 1000 tpmC you must have a 1000 / 12.5 =
81 warehouses. These take about 100 MB apiece.
</p>
	<p>
The benchmark&#39;s working set consists of the STOCK and CUSTOMER tables
of each warehouse and of the ITEM table of the database. Other tables
are accessed more or less sequentially, i.e. inserts to end or deletes
from start. There is a particular distribution of hits for the STOCK
and CUSTOMER rows of each warehouse, leading to a specific working set
within each.
</p>
	<p>
The 160 day rule requires a disk configuration sufficient for accumulating
160 days worth of transactions at the reported rate. For practical
reasons we will ignore this rule here. To just run the benchmark for
the required 20 minutes we will need about twice the space of the initial
data. Let&#39;s assume we have an initial database of 8 GB and have another
16 GB for working space, a total of 24 GB. This is 6 4 GB disks or 12
2 GB ones.
</p>
	<p>
Let&#39;s now look at the relationship between CPU and disk usage. The New
Order transaction, which mostly defines the benchmark&#39;s working set
consists of an average of 10 updates to the STOCK table, which mostly
cause disk reads, 10 reads of the ITEM table which is always in cache,
10 ascending ORDER_LINE inserts, 1 ascending ORDERS insert and 1 CUSTOMER
read plus a DISTRICT update and WAREHOUSE read.
</p>
	<p>
If this happens entirely in RAM this takes about 10 milliseconds on a
200 MHz Pentium Pro, 13 on an Ultra SPARC and so on. Which is roughly
as long a one random disk seek takes.
</p>
	<p>
Because the scaling rule limits RAM to cover only 10% to 20% of the
working set, the STOCK updates will miss the cache most of the time.
This with a transaction mix of New Orders only, we would need about
8 disk seeks to be in progress concurrently in order to feed one CPU.
The other transactions are either more local or repeat the New Order
access profile. Thus we end up needing about 5 concurrent 10 msec disks
for one Power PC 604 and almost double for a 200 MHz Pentium Pro.
</p>
	<p>
For our 24 GB configuration we may as well divide it over as many stripes
as we have disks. For 6 4 GB disks, we would have:
</p>

<div>
      <pre class="screen">
[Striping]
Segment1 = 24G,  /disk1/tpcc-1-1.db = q1, /disk2/tpcc-1-2.db = q2,  /disk3/tpcc-1-3.db = q3,  /disk4/tpcc-1-4.db = q4,  /disk5/tpcc-1-5.db = q5,  /disk6/tpcc-1-6.db = q6
</pre>
    </div>

	<p>
Assuming we have file systems.  Note the I/O queue names q1...q6, meaning that each stripe gets processed on a separate thread for I/O.
</p>
<div class="tip">
      <div class="tiptitle">See</div>
<p>Disk Configuration for more on this.</p>
</div>
	<p>Your Virtuoso may or may not support raw devices.  If it does, they
are specified here.
</p>
	<p>
For the other configuration parameters, we will have sufficient
RAM configured for the DBMS, counting 8.5K of RAM for each buffer.  For
512 MB of RAM, we would have about 25000 buffers. The maximum dirty
parameter is more tricky.  A low number causes unnecessary writing and a
high value causes the number of clean buffers at any time being too low,
causing an imperfect match of the read working set.  The read-only set is
only the ITEM table, about 20 MB.
</p>
<div class="note">
      <div class="notetitle">Note:</div>
<p>Note that about half of the available RAM can efficiently be allocated to the database,
allocating all RAM may result in swapping due to the OS&#39;s disk caching.
In terms of kernel tuning, if one can decrease the OS cache, one may increase the RAM
utilizable by the DBMS without the OS&#39;s disk cache getting in the way.
</p>
    </div>
	<p>
The Stock Level transaction reads lines written by recent New Order
transactions, which are likely to be in RAM and still dirty. The reads
and updates of CUSTOMER are random and generally speaking what is read
is also likely to be or have been updated. We could start with a guess
of 70% maximum dirty, i.e. a value of 70000 for 100000 buffers.
</p>
	<p>
The checkpoint remap should be as large as possible and the unremap quota
should be small. The benchmark does practically no sequential reads and
therefore does not care about disk locality. No limit on remapping means
that a checkpoint can be made in the time it takes to flush the disk
cache. This is done in the background, so that the atomic checkpoint
time is limited to the time it takes to write out those buffers that
became dirty while the first sweep was in progress.
</p>
	<p>
Thus we could have:
</p>

<div>
      <pre class="screen">
MaxCheckpointRemap = 2000000
UnremapQuota = 3000
</pre>
    </div>
<table border="0" width="90%" id="navbarbottom">
    <tr>
        <td align="left" width="33%">
          <a href="omissionsexcp.html" title="Omissions, Exceptions from the Definition">Previous</a>
          <br />Omissions, Exceptions from the Definition</td>
     <td align="center" width="34%">
          <a href="tpcc.html">Chapter Contents</a>
     </td>
        <td align="right" width="33%">
          <a href="otherfactors.html" title="Other Factors">Next</a>
          <br />Other Factors</td>
    </tr>
    </table>
  </div>
  <div id="footer">
    <div>Copyright© 1999 - 2009 OpenLink Software All rights reserved.</div>
   <div id="validation">
    <a href="http://validator.w3.org/check/referer">
        <img src="http://www.w3.org/Icons/valid-xhtml10" alt="Valid XHTML 1.0!" height="31" width="88" />
    </a>
    <a href="http://jigsaw.w3.org/css-validator/">
        <img src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!" height="31" width="88" />
    </a>
   </div>
  </div>
 </body>
</html>