Index: src/docbkx/performance.xml =================================================================== --- src/docbkx/performance.xml (revision 1097898) +++ src/docbkx/performance.xml (working copy) @@ -16,14 +16,14 @@ here for more pointers. Enabling RPC-level logging - Enabling the RPC-level logging on a regionserver can often given + Enabling the RPC-level logging on a RegionServer can often given insight on timings at the server. Once enabled, the amount of log spewed is voluminous. It is not recommended that you leave this logging on for more than short bursts of time. To enable RPC-level - logging, browse to the regionserver UI and click on + logging, browse to the RegionServer UI and click on Log Level. Set the log level to DEBUG for the package org.apache.hadoop.ipc (Thats right, for - hadoop.ipc, NOT, hbase.ipc). Then tail the regionservers log. + hadoop.ipc, NOT, hbase.ipc). Then tail the RegionServers log. Analyze. To disable, set the logging level back to INFO level. @@ -87,7 +87,7 @@
<varname>hbase.regionserver.handler.count</varname> This setting is in essence sets how many requests are - concurrently being processed inside the regionserver at any + concurrently being processed inside the RegionServer at any one time. If set too high, then throughput may suffer as the concurrent requests contend; if set too low, requests will be stuck waiting to get into the machine. You can get a @@ -93,7 +93,7 @@ be stuck waiting to get into the machine. You can get a sense of whether you have too little or too many handlers by - on an individual regionserver then tailing its logs. + on an individual RegionServer then tailing its logs.
@@ -167,7 +167,7 @@ to false on your HTable instance. Otherwise, the Puts will be sent one at a time to the - regionserver. Puts added via htable.add(Put) and htable.add( <List> Put) + RegionServer. Puts added via htable.add(Put) and htable.add( <List> Put) wind up in the same write buffer. If autoFlush = false, these messages are not sent until the write-buffer is filled. To explicitly flush the messages, call flushCommits. @@ -187,7 +187,7 @@ processed. Setting this value to 500, for example, will transfer 500 rows at a time to the client to be processed. There is a cost/benefit to have the cache value be large because it costs more in memory for both - client and regionserver, so bigger isn't always better.
+ client and RegionServer, so bigger isn't always better.
@@ -197,7 +197,7 @@ avoiding performance problems. If you forget to close ResultScanners - you can cause problems on the regionservers. Always have ResultScanner + you can cause problems on the RegionServers. Always have ResultScanner processing enclosed in try/catch blocks... Scan scan = new Scan(); // set attrs... @@ -216,7 +216,7 @@ Scan - instances can be set to use the block cache in the region server via the + instances can be set to use the block cache in the RegionServer via the setCacheBlocks method. For input Scans to MapReduce jobs, this should be false. For frequently accessed rows, it is advisable to use the block cache. @@ -228,7 +228,7 @@ MUST_PASS_ALL operator to the scanner using setFilter. The filter list should include both a FirstKeyOnlyFilter and a KeyOnlyFilter. - Using this filter combination will result in a worst case scenario of a region server reading a single value from disk + Using this filter combination will result in a worst case scenario of a RegionServer reading a single value from disk and minimal network traffic to the client for a single row.