You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@phoenix.apache.org by ja...@apache.org on 2014/10/29 19:24:01 UTC
svn commit: r1635246 - in /phoenix/site: publish/tuning.html
source/src/site/markdown/tuning.md
Author: jamestaylor
Date: Wed Oct 29 18:24:00 2014
New Revision: 1635246
URL: http://svn.apache.org/r1635246
Log:
Update formatting in tuning page
Modified:
phoenix/site/publish/tuning.html
phoenix/site/source/src/site/markdown/tuning.md
Modified: phoenix/site/publish/tuning.html
URL: http://svn.apache.org/viewvc/phoenix/site/publish/tuning.html?rev=1635246&r1=1635245&r2=1635246&view=diff
==============================================================================
--- phoenix/site/publish/tuning.html (original)
+++ phoenix/site/publish/tuning.html Wed Oct 29 18:24:00 2014
@@ -125,7 +125,7 @@
<div class="page-header">
<h1>Configuration and Tuning</h1>
</div>
-<p>Phoenix provides many different knobs and dials to configure and tune the system to run more optimally on your cluster. The configuration is done through a series of Phoenix-specific properties specified for the most part in your client-side <tt>hbase-site.xml</tt> file. In addition to these properties, there are of course all the <a class="externalLink" href="http://hbase.apache.org/book/config.files.html" target="_blank">HBase configuration</a> properties with the most important ones documented <a class="externalLink" href="http://hbase.apache.org/book/important_configurations.html" target="_blank">here</a>. This blog will focus on the Phoenix-specific properties and touch on some important considerations to maximize Phoenix and HBase performance.<br /> <br /> The table below outlines the full set of Phoenix-specific configuration properties and their defaults. Of these, weâll talk in depth about some of the most important ones below.<br /> <br /> </p>
+<p>Phoenix provides many different knobs and dials to configure and tune the system to run more optimally on your cluster. The configuration is done through a series of Phoenix-specific properties specified both on client and server-side <tt>hbase-site.xml</tt> files. In addition to these properties, there are of course all the <a class="externalLink" href="http://hbase.apache.org/book/config.files.html" target="_blank">HBase configuration</a> properties with the most important ones documented <a class="externalLink" href="http://hbase.apache.org/book/important_configurations.html" target="_blank">here</a>.<br /> <br /> The table below outlines the full set of Phoenix-specific configuration properties and their defaults. Of these, weâll talk in depth about some of the most important ones below.<br /> <br /> </p>
<table class="bodyTable table table-striped table-hover" border="1">
<tbody>
<tr class="a">
@@ -150,8 +150,8 @@
</tr>
<tr class="a">
<td><small>phoenix.query.queueSize</small></td>
- <td>Max queue depth of the bounded round robin backing the client side thread pool executor, beyond which an attempt to queue additional work is rejected by throwing an exception. If zero, a SynchronousQueue is used instead of the bounded round robin queue.</td>
- <td>500</td>
+ <td>Max queue depth of the bounded round robin backing the client side thread pool executor, beyond which an attempt to queue additional work is rejected. If zero, a SynchronousQueue is used instead of the bounded round robin queue. The default value is 5000.</td>
+ <td>5000</td>
</tr>
<tr class="b">
<td><small>phoenix.stats.guidepost.width</small></td>
@@ -185,7 +185,7 @@
</tr>
<tr class="b">
<td><small>phoenix.query.maxSpoolToDiskBytes</small></td>
- <td style="text-align: left;">Threshold size in bytes up to which results from parallelly executed query results are spooled to disk above which the query will fail. Default is 1 gb.</td>
+ <td style="text-align: left;">Threshold size in bytes up to which results from parallelly executed query results are spooled to disk above which the query will fail. Default is 1 GB.</td>
<td>1024000000</td>
</tr>
<tr class="a">
@@ -376,7 +376,7 @@
<div class="section">
<h4 id="Parallelization"> Parallelization</h4>
<p>Phoenix breaks up queries into multiple scans and runs them in parallel through coprocessors to improve performance. Hari Kumar, from Ericsson Labs, did a good job of explaining the performance benefits of parallelization and coprocessors <a class="externalLink" href="http://labs.ericsson.com/blog/hbase-performance-tuners" target="_blank">here</a>.</p>
- <p>As of 3.2/4.2, parallelization in Phoenix is driven by the guideposts as determined by the configuration parameters for <a class="externalLink" href="http://phoenix.apache.org/update_statistics.html">statistics collection</a>. Each chunk of data between guideposts will be run in parallel in a separate scan to improve query performance. The chunk size is determined by the server-side <tt>phoenix.stats.guidepost.width</tt> or <tt>phoenix.stats.guidepost.per.region</tt> configuration parameters. Note that at a minimum, separate scans will be run for each table region. Beyond the statistics collection configuration parameters, the client-side <tt>phoenix.query.threadPoolSize</tt> and <tt>phoenix.query.queueSize</tt> parameters and the server-side <tt>hbase.regionserver.handler.count</tt> parameter have an impact on performance.</p>
+ <p>As of 3.2/4.2, parallelization in Phoenix is driven by the guideposts as determined by the configuration parameters for <a class="externalLink" href="http://phoenix.apache.org/update_statistics.html">statistics collection</a>. Each chunk of data between guideposts will be run in parallel in a separate scan to improve query performance. The chunk size is determined by the server-side <tt>phoenix.stats.guidepost.width</tt> or <tt>phoenix.stats.guidepost.per.region</tt> configuration parameters. As the size of the chunks decrease, you'll want to increase <tt>phoenix.query.queueSize</tt> as more work will be queued in that case. Note that at a minimum, separate scans will be run for each table region. Beyond the statistics collection configuration parameters, the client-side <tt>phoenix.query.threadPoolSize</tt> and <tt>phoenix.query.queueSize</tt> parameters and the server-side <tt>hbase.regionserver.handler.count</tt> parameter have an impact on performance.</p>
</div>
</div>
</div>
Modified: phoenix/site/source/src/site/markdown/tuning.md
URL: http://svn.apache.org/viewvc/phoenix/site/source/src/site/markdown/tuning.md?rev=1635246&r1=1635245&r2=1635246&view=diff
==============================================================================
--- phoenix/site/source/src/site/markdown/tuning.md (original)
+++ phoenix/site/source/src/site/markdown/tuning.md Wed Oct 29 18:24:00 2014
@@ -1,6 +1,6 @@
# Configuration and Tuning
-Phoenix provides many different knobs and dials to configure and tune the system to run more optimally on your cluster. The configuration is done through a series of Phoenix-specific properties specified for the most part in your client-side <code>hbase-site.xml</code> file. In addition to these properties, there are of course all the <a href="http://hbase.apache.org/book/config.files.html" target="_blank">HBase configuration</a> properties with the most important ones documented <a href="http://hbase.apache.org/book/important_configurations.html" target="_blank">here</a>. This blog will focus on the Phoenix-specific properties and touch on some important considerations to maximize Phoenix and HBase performance.<br />
+Phoenix provides many different knobs and dials to configure and tune the system to run more optimally on your cluster. The configuration is done through a series of Phoenix-specific properties specified both on client and server-side <code>hbase-site.xml</code> files. In addition to these properties, there are of course all the <a href="http://hbase.apache.org/book/config.files.html" target="_blank">HBase configuration</a> properties with the most important ones documented <a href="http://hbase.apache.org/book/important_configurations.html" target="_blank">here</a>.<br/>
<br />
The table below outlines the full set of Phoenix-specific configuration properties and their defaults. Of these, we'll talk in depth about some of the most important ones below.<br />
<br />
@@ -24,8 +24,8 @@ increased.</td><td>128</td></tr>
of the
bounded round robin backing the client side thread pool executor,
beyond which an attempt to queue additional work is
- rejected by throwing an exception. If zero, a SynchronousQueue is used
- instead of the bounded round robin queue.</td><td>500</td></tr>
+ rejected. If zero, a SynchronousQueue is used
+ instead of the bounded round robin queue. The default value is 5000.</td><td>5000</td></tr>
<tr><td><small>phoenix.stats.guidepost.width</small></td><td>
A server-side parameter that specifies the number of bytes between guideposts.
A smaller amount increases parallelization, but also increases the number of
@@ -61,7 +61,7 @@ An advanced server-side parameter that i
query results are spooled to disk. Default is 20 mb.</td><td>20971520</td></tr>
<tr><td><small>phoenix.query.maxSpoolToDiskBytes</small></td><td style="text-align: left;">Threshold
size in bytes up to which results from parallelly executed
- query results are spooled to disk above which the query will fail. Default is 1 gb.</td><td>1024000000</td></tr>
+ query results are spooled to disk above which the query will fail. Default is 1 GB.</td><td>1024000000</td></tr>
<tr><td><small>phoenix.query.maxGlobalMemoryPercentage</small></td><td style="text-align: left;">Percentage of total heap memory (i.e. Runtime.getRuntime().maxMemory()) that all threads may use. Only course grain memory usage is tracked, mainly accounting for memory usage in the intermediate map built during group by aggregation. When this limit is reached the clients block attempting to get more memory, essentially throttling memory usage. Defaults to 15%</td><td>15</td></tr>
<tr><td><small>phoenix.query.maxGlobalMemorySize</small></td><td style="text-align: left;">Max size in bytes of total tracked memory usage. By default not specified, however, if present, the lower of this parameter and the phoenix.query.maxGlobalMemoryPercentage will be used
</td><td> </td></tr>
@@ -153,7 +153,9 @@ Parallelization</h4>
parameters for <a href="http://phoenix.apache.org/update_statistics.html">statistics collection</a>. Each
chunk of data between guideposts will be run in parallel in a separate scan to improve query performance.
The chunk size is determined by the server-side <code>phoenix.stats.guidepost.width</code> or
-<code>phoenix.stats.guidepost.per.region</code> configuration parameters. Note that at a minimum, separate
+<code>phoenix.stats.guidepost.per.region</code> configuration parameters. As the size of the chunks decrease,
+you'll want to increase <code>phoenix.query.queueSize</code> as more work will be queued in that case. Note
+that at a minimum, separate
scans will be run for each table region. Beyond the statistics collection configuration parameters,
the client-side <code>phoenix.query.threadPoolSize</code> and <code>phoenix.query.queueSize</code> parameters
and the server-side <code>hbase.regionserver.handler.count</code> parameter have an impact on performance.</p>