[jira] [Commented] (HBASE-4462) Properly treating SocketTimeoutException
[
https://issues.apache.org/jira/browse/HBASE-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114611#comment-13114611
]
subramanian raghunathan commented on HBASE-4462:
The fix in defect HBASE-2937 looks big,but the actual patch that got committed
is present in the review board and it seems to be simple.
The fix also facilitates "Timeouts In HBase Client".Else theres only a retry
times {numRetries} that defines the behaviour and its not based on time perioed
, which seems to be a value addition.
Plz sugest!
Meanwhile i will try to apply the patch in .90.x and see if there are any major
hurdles and post the result.
> Properly treating SocketTimeoutException
>
>
> Key: HBASE-4462
> URL: https://issues.apache.org/jira/browse/HBASE-4462
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 0.90.4
>Reporter: Jean-Daniel Cryans
> Fix For: 0.92.0
>
>
> SocketTimeoutException is currently treated like any IOE inside of
> HCM.getRegionServerWithRetries and I think this is a problem. This method
> should only do retries in cases where we are pretty sure the operation will
> complete, but with STE we already waited for (by default) 60 seconds and
> nothing happened.
> I found this while debugging Douglas Campbell's problem on the mailing list
> where it seemed like he was using the same scanner from multiple threads, but
> actually it was just the same client doing retries while the first run didn't
> even finish yet (that's another problem). You could see the first scanner,
> then up to two other handlers waiting for it to finish in order to run
> (because of the synchronization on RegionScanner).
> So what should we do? We could treat STE as a DoNotRetryException and let the
> client deal with it, or we could retry only once.
> There's also the option of having a different behavior for get/put/icv/scan,
> the issue with operations that modify a cell is that you don't know if the
> operation completed or not (same when a RS dies hard after completing let's
> say a Put but just before returning to the client).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4462) Properly treating SocketTimeoutException
[
https://issues.apache.org/jira/browse/HBASE-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113312#comment-13113312
]
subramanian raghunathan commented on HBASE-4462:
What i observed in trunk code is HCM.getRegionServerWithRetries()
{code}
try {
callable.instantiateServer(tries != 0);
callable.beforeCall();
return callable.call();
} catch (Throwable t) {
callable.shouldRetry(t);
t = translateException(t);
exceptions.add(t);
if (tries == numRetries - 1) {
throw new RetriesExhaustedException(callable.getServerName(),
callable.getRegionName(), callable.getRow(), tries, exceptions);
}
} finally {
callable.afterCall();
}
public void shouldRetry(Throwable throwable) throws IOException {
if (this.callTimeout != HConstants.DEFAULT_HBASE_CLIENT_OPERATION_TIMEOUT)
if (throwable instanceof SocketTimeoutException
|| (this.endTime - this.startTime > this.callTimeout)) {
throw (SocketTimeoutException) (SocketTimeoutException) new
SocketTimeoutException(
"Call to access row '" + Bytes.toString(row) + "' on table '"
+ Bytes.toString(tableName)
+ "' failed on socket timeout exception: " + throwable)
.initCause(throwable);
} else {
this.callTimeout = ((int) (this.endTime - this.startTime));
}
}
{code}
shouldRetry handles the SocketTimeoutException in a specific manner as such
theres no
retrytimes or period if its SocketTimeoutException and the exception is
immediately thrown back.
This is handled as a part of the defect {HBASE-2937:Facilitate Timeouts In
HBase Client}
But the same is not present in 0.90.x. Does the fix in HBASE-2937 and current
JIRA related ? If so can we backport ?
Please correct me if i am wrong some where.
> Properly treating SocketTimeoutException
>
>
> Key: HBASE-4462
> URL: https://issues.apache.org/jira/browse/HBASE-4462
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 0.90.4
>Reporter: Jean-Daniel Cryans
> Fix For: 0.92.0
>
>
> SocketTimeoutException is currently treated like any IOE inside of
> HCM.getRegionServerWithRetries and I think this is a problem. This method
> should only do retries in cases where we are pretty sure the operation will
> complete, but with STE we already waited for (by default) 60 seconds and
> nothing happened.
> I found this while debugging Douglas Campbell's problem on the mailing list
> where it seemed like he was using the same scanner from multiple threads, but
> actually it was just the same client doing retries while the first run didn't
> even finish yet (that's another problem). You could see the first scanner,
> then up to two other handlers waiting for it to finish in order to run
> (because of the synchronization on RegionScanner).
> So what should we do? We could treat STE as a DoNotRetryException and let the
> client deal with it, or we could retry only once.
> There's also the option of having a different behavior for get/put/icv/scan,
> the issue with operations that modify a cell is that you don't know if the
> operation completed or not (same when a RS dies hard after completing let's
> say a Put but just before returning to the client).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-3958) use Scan with setCaching() and PageFilter have a problem
[
https://issues.apache.org/jira/browse/HBASE-3958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109279#comment-13109279
]
subramanian raghunathan commented on HBASE-3958:
As per Jerry Du:
Rangs means Cross regions Scan(multi-regions scan).
The issue is my first HBase program, the following is P-code:
create a table which is preSplit 100 regions;
each region have 100 rows;
fill data with row key [0,]
Scan with startKey and stopKey which cross all regions;[0,)
scan.setCaching(3);
scan.setFilter(new PageFilter(5));
the out put is:
Row key:
0
1
2
caching border
3
4
region_0 with filter border
5
caching border
6
7
8
caching border
9
region_1 with filter border
10
11
caching border
12
13
14
caching border AND region_2 with filter border
Case another
scan.setCaching(2);
scan.setFilter(new PageFilter(5));
Output will be
Row key:
0
1
caching border
2
3
caching border
4
region_0 with filter border
5
caching border
6
7
caching border
8
9
caching border AND region_1 with filter border
scan stop in both caching and region border
The Reason is two:
Filter instance is only in one region scan;
in method org.apache.hadoop.hbase.clien.HTable.ClientScanner.next()
do {} while (remainingResultSize > 0 && countdown > 0 && nextScanner(countdown,
values == null));
the stop condition is NOT consider scan with Filter
NOT Only PageFilter,any filter will be problem in cross regions
scan(multi-regions scan).
> use Scan with setCaching() and PageFilter have a problem
>
>
> Key: HBASE-3958
> URL: https://issues.apache.org/jira/browse/HBASE-3958
> Project: HBase
> Issue Type: Bug
> Components: filters, regionserver
>Affects Versions: 0.90.3
> Environment: Linux testbox 2.6.18-238.el5 #1 SMP Sun Dec 19 14:22:44
> EST 2010 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.6.0_23"
> Java(TM) SE Runtime Environment (build 1.6.0_23-b05)
> Java HotSpot(TM) 64-Bit Server VM (build 19.0-b09, mixed mode)
>Reporter: Jerry Du
>Priority: Minor
>
> I have a table with 3 ranges,then I scan the table cross all 3 ranges.
> Scan scan = new Scan();
> scan.setCaching(10);
> scan.setFilter(new PageFilter(21));
> [result rows count = 63]
> the Result has 63 rows, each range has scaned,and locally limit to
> page_szie.That is expect result.
> Then if the page_size = N * caching_size, then result has only page_size
> rows,only the first range has scanned.
> If page_size is Multiple of caching_size,one range rsult just align fill the
> caching,then client NOT trrige next range scan.
> Example:
> Scan scan = new Scan();
> scan.setCaching(10);
> scan.setFilter(new PageFilter(20));
> [result rows count = 20]
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4304) requestsPerSecond counter stuck at 0
[ https://issues.apache.org/jira/browse/HBASE-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13100263#comment-13100263 ] subramanian raghunathan commented on HBASE-4304: @LiPi are you working on this patch? > requestsPerSecond counter stuck at 0 > > > Key: HBASE-4304 > URL: https://issues.apache.org/jira/browse/HBASE-4304 > Project: HBase > Issue Type: Bug > Components: master, regionserver >Affects Versions: 0.92.0 >Reporter: Todd Lipcon >Assignee: Li Pi >Priority: Critical > Fix For: 0.92.0 > > > Running trunk @ r1163343, all of the requestsPerSecond counters are showing 0 > both in the master UI and in the RS UI. The writeRequestsCount metric is > properly updating in the RS UI. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4304) requestsPerSecond counter stuck at 0
[
https://issues.apache.org/jira/browse/HBASE-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13100261#comment-13100261
]
subramanian raghunathan commented on HBASE-4304:
What i felt as corrective action could be is like :
{code}
protected void metrics() {
this.metrics.regions.set(this.onlineRegions.size());
this.metrics.incrementRequests(this.requestCount.get());
//TODO:compute the request per second here
{code}
{color:green}//TODO:compute the request per second here {color}
So the the request per second value will be fixed till the next run
which will be recalculated in the next run and the counter is reset to zero as
part of
{code}
void tryRegionServerReport()
throws IOException {
HServerLoad hsl = buildServerLoad();
// Why we do this?
this.requestCount.set(0);
{code}
{color:red}But this has a contradiction with the usage of context based metrics
update , when the context is enabled.
There could be a chance of race in the computation of the value.
The race will be resetting of the value to zero {this.value = 0;}
after computation {color}
{code}
private synchronized void intervalHeartBeat() {
long now = System.currentTimeMillis();
long diff = (now-ts)/1000;
if (diff == 0) diff = 1; // sigh this is crap.
this.prevRate = (float)value / diff;
this.value = 0;
this.ts = now;
}
{code}
> requestsPerSecond counter stuck at 0
>
>
> Key: HBASE-4304
> URL: https://issues.apache.org/jira/browse/HBASE-4304
> Project: HBase
> Issue Type: Bug
> Components: master, regionserver
>Affects Versions: 0.92.0
>Reporter: Todd Lipcon
>Assignee: Li Pi
>Priority: Critical
> Fix For: 0.92.0
>
>
> Running trunk @ r1163343, all of the requestsPerSecond counters are showing 0
> both in the master UI and in the RS UI. The writeRequestsCount metric is
> properly updating in the RS UI.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4304) requestsPerSecond counter stuck at 0
[
https://issues.apache.org/jira/browse/HBASE-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13100252#comment-13100252
]
subramanian raghunathan commented on HBASE-4304:
I want to provide my analysis & background since its relatd to HBASE-3807 fixed
by me earlier
1) Previously the problem was present only in the region server.
As part of defect
HBASE-3807:Fix units in RS UI metrics
I had changed the HServerLoad also to use the region server metrics and made it
to be consistent as {color:green}requestPerSecond {color}.
{code}
return new HServerLoad(requestCount.get(),(int)metrics.getRequests(),
(int)(memory.getUsed() / 1024 / 1024),
(int) (memory.getMax() / 1024 / 1024), regionLoads);
{code}
Request per second value derived from here
:{color:green}(int)metrics.getRequests(){color}
2) But what i missed to find out was the region server metrics itself was not
functioning properly.
Digged in and found following things.
1) HRegionServer.run() method is the major source of value provided for
request.It runs by default every three seconds
{code}
if ((now - lastMsg) >= msgInterval) {
{code}
The request count is populated here into the metrics as part of the doMetrics
method.
{code}
this.metrics.incrementRequests(this.requestCount.get())
{code}
will go and update the metrics rate thro the method
{code}
public synchronized void inc(final int incr) {
value += incr;
}
{code}
{color:green}This gives the request received between the previous run and
current run.{color}
But the request per second value will be populated only when the following
piece gets executed of the class MetricsRate
{code}
private synchronized void intervalHeartBeat() {
long now = System.currentTimeMillis();
long diff = (now-ts)/1000;
if (diff == 0) diff = 1; // sigh this is crap.
this.prevRate = (float)value / diff;
this.value = 0;
this.ts = now;
}
@Override
public synchronized void pushMetric(final MetricsRecord mr) {
intervalHeartBeat();
try {
mr.setMetric(getName(), getPreviousIntervalValue());
} catch (Exception e) {
LOG.info("pushMetric failed for " + getName() + "\n" +
StringUtils.stringifyException(e));
}
}
{code}
{color:red} pushMetric wont be invoked by default since the metrics won't be
enabled by default
hbase.class=org.apache.hadoop.metrics.spi.NullContext.
Please do correct me if i am wrong here{color}
So ideally the value is always displayed as zero.
> requestsPerSecond counter stuck at 0
>
>
> Key: HBASE-4304
> URL: https://issues.apache.org/jira/browse/HBASE-4304
> Project: HBase
> Issue Type: Bug
> Components: master, regionserver
>Affects Versions: 0.92.0
>Reporter: Todd Lipcon
>Assignee: Li Pi
>Priority: Critical
> Fix For: 0.92.0
>
>
> Running trunk @ r1163343, all of the requestsPerSecond counters are showing 0
> both in the master UI and in the RS UI. The writeRequestsCount metric is
> properly updating in the RS UI.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4215) RS requestsPerSecond counter seems to be off
[ https://issues.apache.org/jira/browse/HBASE-4215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] subramanian raghunathan updated HBASE-4215: --- Status: Patch Available (was: Open) > RS requestsPerSecond counter seems to be off > > > Key: HBASE-4215 > URL: https://issues.apache.org/jira/browse/HBASE-4215 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 0.92.0 >Reporter: Todd Lipcon >Assignee: subramanian raghunathan >Priority: Critical > Fix For: 0.92.0 > > Attachments: HBASE-4215_trunk.patch > > > In testing trunk, I had YCSB reporting some 40,000 requests/second, but the > summary info on the master webpage was consistently indicating somewhere > around 3x that. I'm guessing that we may have a bug where we forgot to divide > by time. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4215) RS requestsPerSecond counter seems to be off
[ https://issues.apache.org/jira/browse/HBASE-4215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] subramanian raghunathan updated HBASE-4215: --- Attachment: HBASE-4215_trunk.patch > RS requestsPerSecond counter seems to be off > > > Key: HBASE-4215 > URL: https://issues.apache.org/jira/browse/HBASE-4215 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 0.92.0 >Reporter: Todd Lipcon >Assignee: subramanian raghunathan >Priority: Critical > Fix For: 0.92.0 > > Attachments: HBASE-4215_trunk.patch > > > In testing trunk, I had YCSB reporting some 40,000 requests/second, but the > summary info on the master webpage was consistently indicating somewhere > around 3x that. I'm guessing that we may have a bug where we forgot to divide > by time. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4215) RS requestsPerSecond counter seems to be off
[
https://issues.apache.org/jira/browse/HBASE-4215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13088577#comment-13088577
]
subramanian raghunathan commented on HBASE-4215:
1) Modifying the requestPersecond value to integer rather than float since the
value is used in several VO's
like:
1) MasterMetrics metrics
2) AClusterStatus
3) StorageClusterStatusModel
4) AServerLoad etc.
Also to maintain consistensy the regionservermetrics and HServerLoad using
integer values for requestPersecond.
Advantages: Consitency throughout the system . Changes are minimal.
DisAdvantages: Percision loss, also integer can accomadate less value than the
float.
2)HServerLoad.getNumberOfRequests() is used in multiple places.
{color:green}StorageClusterStatusModel - Expects request per second
ClusterStatus - Expects request per second
MasterStatusTmplImpl - UI part also Expects request per second {color}
{color:red}AvroUtil - Not sure {color}
{color:red}
HMaster
public void regionServerReport(final byte [] sn, final HServerLoad hsl)
throws IOException {
this.serverManager.regionServerReport(new ServerName(sn), hsl);
if (hsl != null && this.metrics != null) {
// Up our metrics.
this.metrics.incrementRequests(hsl.getTotalNumberOfRequests());
}
}
The metric expects the total request in the all the region servers and the
metric computes the per second value of the aggregation of all the region
servers.{color}
So following change is sugested to keep the existing attribute as the
requestPersecond.Also introduce additional attribute that reports the total
request made in RS as totalNumberOfRequests This will be used by the Master
Metrics.
Will upload the patch ASAP
> RS requestsPerSecond counter seems to be off
>
>
> Key: HBASE-4215
> URL: https://issues.apache.org/jira/browse/HBASE-4215
> Project: HBase
> Issue Type: Bug
> Components: metrics
>Affects Versions: 0.92.0
>Reporter: Todd Lipcon
>Assignee: ramkrishna.s.vasudevan
>Priority: Critical
> Fix For: 0.92.0
>
>
> In testing trunk, I had YCSB reporting some 40,000 requests/second, but the
> summary info on the master webpage was consistently indicating somewhere
> around 3x that. I'm guessing that we may have a bug where we forgot to divide
> by time.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4215) RS requestsPerSecond counter seems to be off
[ https://issues.apache.org/jira/browse/HBASE-4215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087014#comment-13087014 ] subramanian raghunathan commented on HBASE-4215: In further to these understandindg , i was planning to unify the methodology of deriving the "requestPerSecond" , so that HRsgionServer uses the APi of RegionServerMetrics (i.e) RegionServerMetrics.getRequests() and initialise HServerLoad , but one desparity found was metricsState uses a float value whereas HServerLoad uses an integer value to represent the same,It would be better to unify the data type across them so that the master and region server UI are in sink. Please sugest me which of them can be used and unified,i personally feel float is better but the changes seem to be more. Based on that i will provide the patch tommorow. > RS requestsPerSecond counter seems to be off > > > Key: HBASE-4215 > URL: https://issues.apache.org/jira/browse/HBASE-4215 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 0.92.0 >Reporter: Todd Lipcon >Assignee: ramkrishna.s.vasudevan >Priority: Critical > Fix For: 0.92.0 > > > In testing trunk, I had YCSB reporting some 40,000 requests/second, but the > summary info on the master webpage was consistently indicating somewhere > around 3x that. I'm guessing that we may have a bug where we forgot to divide > by time. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4215) RS requestsPerSecond counter seems to be off
[
https://issues.apache.org/jira/browse/HBASE-4215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086939#comment-13086939
]
subramanian raghunathan commented on HBASE-4215:
As part of the defect fix HBASE-3807
we proposed and modified the request attribute to
requestPersecond both in RegionServer{RegionServerMetrics} and
Master{HServerLoad}
RegionServerMetrics calcualtes from MetricsRate
Following is the code doing the calcualtion:
{code}
long now = System.currentTimeMillis();
long diff = (now-ts)/1000;
if (diff == 0) diff = 1; // sigh this is crap.
this.prevRate = (float)value / diff;
{code}
{color:red}this.prevRate = (float)value / diff;{color}
prevRate is finally displayed as "requestPersecond" as per the change in
HBASE-3807
But in master the same is calculated from HServerLoad
HRegionServer.buildServerLoad()
{code}
new HServerLoad(requestCount.get(),
(int)(memory.getUsed() / 1024 / 1024),
(int) (memory.getMax() / 1024 / 1024), regionLoads)
{code}
Request counter is present in HregionServer
{code}
// Request counter.
// Do we need this? Can't we just sum region counters? St.Ack 20110412
private AtomicInteger requestCount = new AtomicInteger();
{code}
Obtained form the request counter which is incremented in all the API's of
HRegionServer
{color:red}This is not calculated per second its representing the total request
per second.{color}
but still in the master page we claim {color:green}"Load is requests per second
and count of regions loaded."{color}
This promted me in changing the convention from request to resquestPerSecond
{color:green}Ideally The fix should be calculating the requestpersecond at
region server and
initializing the HServerLoad with that value and the same to be displayed in
the master.{color}
Region Servers
Address Start Code Load
linux-kxjl:60030 1313659887824linux-kxjl,60020,1313659887824
requestsPerSecond=0, numberOfOnlineRegions=2, usedHeapMB=26, maxHeapMB=995
Total: servers: 1 requests=0, regions=2
Load is requests per second and count of regions loaded
Also its better to change the agregation details also into the new convention
{color:red} requests=0, regions=2{color}
to
{color:green} requestsPerSecond=0, numberOfOnlineRegions=2{color}
If this looks fine i can provide a patch for the same.
> RS requestsPerSecond counter seems to be off
>
>
> Key: HBASE-4215
> URL: https://issues.apache.org/jira/browse/HBASE-4215
> Project: HBase
> Issue Type: Bug
> Components: metrics
>Affects Versions: 0.92.0
>Reporter: Todd Lipcon
>Assignee: ramkrishna.s.vasudevan
>Priority: Critical
> Fix For: 0.92.0
>
>
> In testing trunk, I had YCSB reporting some 40,000 requests/second, but the
> summary info on the master webpage was consistently indicating somewhere
> around 3x that. I'm guessing that we may have a bug where we forgot to divide
> by time.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-3807) Fix units in RS UI metrics
[ https://issues.apache.org/jira/browse/HBASE-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] subramanian raghunathan updated HBASE-3807: --- Status: Patch Available (was: Open) > Fix units in RS UI metrics > -- > > Key: HBASE-3807 > URL: https://issues.apache.org/jira/browse/HBASE-3807 > Project: HBase > Issue Type: Bug >Reporter: stack > Fix For: 0.94.0 > > Attachments: HBASE-3807_trunk.patch > > > Currently the metrics are a mix of MB and bytes. Its confusing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-3807) Fix units in RS UI metrics
[ https://issues.apache.org/jira/browse/HBASE-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] subramanian raghunathan updated HBASE-3807: --- Attachment: HBASE-3807_trunk.patch > Fix units in RS UI metrics > -- > > Key: HBASE-3807 > URL: https://issues.apache.org/jira/browse/HBASE-3807 > Project: HBase > Issue Type: Bug >Reporter: stack > Fix For: 0.94.0 > > Attachments: HBASE-3807_trunk.patch > > > Currently the metrics are a mix of MB and bytes. Its confusing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-3807) Fix units in RS UI metrics
[
https://issues.apache.org/jira/browse/HBASE-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13082296#comment-13082296
]
subramanian raghunathan commented on HBASE-3807:
Removing the unused code for determining time elapsed in RegionServerMetrics :
int seconds = (int)((System.currentTimeMillis() - this.lastUpdate)/1000);
if (seconds == 0) {
seconds = 1;
}
Will upload the patch ASAP
> Fix units in RS UI metrics
> --
>
> Key: HBASE-3807
> URL: https://issues.apache.org/jira/browse/HBASE-3807
> Project: HBase
> Issue Type: Bug
>Reporter: stack
> Fix For: 0.94.0
>
>
> Currently the metrics are a mix of MB and bytes. Its confusing.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-3807) Fix units in RS UI metrics
[
https://issues.apache.org/jira/browse/HBASE-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13082295#comment-13082295
]
subramanian raghunathan commented on HBASE-3807:
Also modifying the debug log in LruBlockCache since theres duplicate
percentages{%%} in cachingHitsRatio & hitRatio
2011-08-09 11:39:52,227 DEBUG org.apache.hadoop.hbase.io.hfile.LruBlockCache:
LRU Stats: total=960.27 KB, free=198.75 MB, max=199.69 MB, blocks=2,
accesses=19, hits=17, {color:red}hitRatio=89.47%%{color}, cachingAccesses=19,
cachingHits=17, {color:red}cachingHitsRatio=89.47%%{color}, evictions=0,
evicted=0, evictedPerRun=NaN
after fix
2011-08-10 10:58:59,062 DEBUG org.apache.hadoop.hbase.io.hfile.LruBlockCache:
LRU Stats: total=1.65 MB, free=197.53 MB, max=199.18 MB, blocks=4, accesses=83,
hits=79, {color:green}hitRatio=95.18%{color}, cachingAccesses=83,
cachingHits=79, {color:green}cachingHitsRatio=95.18%{color}, evictions=0,
evicted=0, evictedPerRun=NaN
> Fix units in RS UI metrics
> --
>
> Key: HBASE-3807
> URL: https://issues.apache.org/jira/browse/HBASE-3807
> Project: HBase
> Issue Type: Bug
>Reporter: stack
> Fix For: 0.94.0
>
>
> Currently the metrics are a mix of MB and bytes. Its confusing.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-3807) Fix units in RS UI metrics
[
https://issues.apache.org/jira/browse/HBASE-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13082150#comment-13082150
]
subramanian raghunathan commented on HBASE-3807:
requestsPerSecond=0.0, numberOfOnlineRegions=8, numberOfStores=8,
numberOfStorefiles=8, storefileIndexSizeMB=0, rootIndexSizeKB=3,
totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0, memstoreSizeMB=0,
readRequestsCount=48, writeRequestsCount=8, compactionQueueSize=0,
flushQueueSize=0, usedHeapMB=38, maxHeapMB=995,
{color:green}blockCacheSizeMB=1.65, blockCacheFreeMB=197.53{color},
blockCacheCount=4, blockCacheHitCount=79, blockCacheMissCount=4,
blockCacheEvictedCount=0, blockCacheHitRatio=95%, blockCacheHitCachingRatio=95%
> Fix units in RS UI metrics
> --
>
> Key: HBASE-3807
> URL: https://issues.apache.org/jira/browse/HBASE-3807
> Project: HBase
> Issue Type: Bug
>Reporter: stack
> Fix For: 0.94.0
>
>
> Currently the metrics are a mix of MB and bytes. Its confusing.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-3807) Fix units in RS UI metrics
[
https://issues.apache.org/jira/browse/HBASE-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081586#comment-13081586
]
subramanian raghunathan commented on HBASE-3807:
Proposing to change from the following formats
request=0.0, regions=8, stores=8, storefiles=8, storefileIndexSize=0,
rootIndexSizeKB=3, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0,
memstoreSize=0, readRequestsCount=56, writeRequestsCount=14,
compactionQueueSize=0, flushQueueSize=0, usedHeap=41, maxHeap=995,
blockCacheSize=1767336, blockCacheFree=207082792, blockCacheCount=9,
blockCacheHitCount=50, blockCacheMissCount=9, blockCacheEvictedCount=0,
blockCacheHitRatio=84, blockCacheHitCachingRatio=84
stores=1, storefiles=2, storefileUncompressedSizeMB=0, storefileSizeMB=0,
memstoreSizeMB=0, storefileIndexSizeMB=0, readRequestsCount=8,
writeRequestsCount=2, rootIndexSizeKB=0, totalStaticIndexSizeKB=0,
totalStaticBloomSizeKB=0
to
{color:red}requestsPerSecond=0.0, numberOfOnlineRegions=8, numberOfStores=8,
numberOfStorefiles=10, storefileIndexSizeMB=0{color}, rootIndexSizeKB=4,
totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0,
{color:red}memstoreSizeMB=0{color}, readRequestsCount=48, writeRequestsCount=8,
compactionQueueSize=0, flushQueueSize=0,{color:red}usedHeapMB=34,
maxHeapMB=995, blockCacheSizeMB=1.6885986, blockCacheFreeMB=197.4864{color},
blockCacheCount=11, blockCacheHitCount=53, blockCacheMissCount=11,
blockCacheEvictedCount=0, {color:red}blockCacheHitRatio=82%,
blockCacheHitCachingRatio=82%{color}
{color:red}numberOfStores=1, numberOfStorefiles=3{color},
storefileUncompressedSizeMB=0, storefileSizeMB=0,memstoreSizeMB=0,
storefileIndexSizeMB=0, readRequestsCount=8, writeRequestsCount=2,
rootIndexSizeKB=1, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0
Also proposing the following metric in bytes blockCacheSize ,blockCacheFree
planning to MB with full precision like
{color:green}blockCacheSizeMB=1.6885986, blockCacheFreeMB=197.4864{color}
If this looks good ,i can upload the patch for trunk. If needed i can prepare
the patch for 90.X also.
> Fix units in RS UI metrics
> --
>
> Key: HBASE-3807
> URL: https://issues.apache.org/jira/browse/HBASE-3807
> Project: HBase
> Issue Type: Bug
>Reporter: stack
> Fix For: 0.94.0
>
>
> Currently the metrics are a mix of MB and bytes. Its confusing.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
