[
https://issues.apache.org/jira/browse/HBASE-4689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Kyle Purtell resolved HBASE-4689.
Resolution: Fixed
> [89-fb] Make the table level metrics work with rpc* metr
Chenxi Tong created HBASE-18869:
---
Summary: Table rpc metrics
Key: HBASE-18869
URL: https://issues.apache.org/jira/browse/HBASE-18869
Project: HBase
Issue Type: Wish
Components
Ted Yu created HBASE-9194:
-
Summary: Add RPC metrics to metrics2
Key: HBASE-9194
URL: https://issues.apache.org/jira/browse/HBASE-9194
Project: HBase
Issue Type: Task
Reporter: Ted Yu
We have to add the two missing metrics:
public MetricsIntValue numOpenConnections =
new MetricsIntValue("NumOpenConnections", registry);
public MetricsIntValue callQueueLen =
new MetricsIntValue("callQueueLen", registry);
Plus the wiring for them, which is like 10 lines of
On Thu, May 19, 2011 at 6:55 AM, Lars George wrote:
> Ah, I see now, got myself fooled. This was added maybe after we clones
> the RpcMetrics into HBaseRpcMetrics. So all we have to do is add it to
> be back up to parity (and then some).
>
Do we have to fix something boss?
St.Ack
Ah, I see now, got myself fooled. This was added maybe after we clones
the RpcMetrics into HBaseRpcMetrics. So all we have to do is add it to
be back up to parity (and then some).
On Wed, May 18, 2011 at 6:58 PM, Lars George wrote:
> I am not sure how though. I checked and they seem to be registe
So, running YSCB, which uses the client-side write buffer, you see this
multiPut_avg_time=0,
multiPut_num_ops=0,
multi_avg_time=0,
multi_num_ops=391,
put_avg_time=0,
put_num_ops=41,
the put_num_ops was at 41 before, so was not incremented. Internally
the HTable uses the new multi() call, which is
I am not sure how though. I checked and they seem to be registered
correctly. Even if they are not set, JMX should show them. But nada,
zip, zero, zilch.
Couldn't be bothered (yet) compiling a LOG.debug() version of
hadoop-core to check where they went up shits creek.
On Wed, May 18, 2011 at 4:42
Hi Mathias,
Keep in mind that they are kept as MetricsTimeVaryingRate meaning they
trail by "period" seconds. The values are accrued over the poll
interval and then updated at the end.
But you are saying there is a huge difference? I think this is due to
the puts not actually using puts anymore,
On Wed, May 18, 2011 at 7:48 AM, Mathias Herberts
wrote:
> While on the topic of metrics, some of them seem misleading,
>
> in my setup, 'hbase.metrics.put_num_ops' does not seem to reflect the
> number of put ops received by a RS, it's simply way below and seems to
> only reflect puts done in .ME
While on the topic of metrics, some of them seem misleading,
in my setup, 'hbase.metrics.put_num_ops' does not seem to reflect the
number of put ops received by a RS, it's simply way below and seems to
only reflect puts done in .META., is that supposed to be the case?
On Wed, May 18, 2011 at 16:
MIA I'd say. They look useful.
St.Ack
On Wed, May 18, 2011 at 6:34 AM, Lars George wrote:
> Hi,
>
> Did anyone else notice that the RPCMetrics are supposed to export four
> internal values:
>
> public MetricsTimeVaryingRate rpcQueueTime =
> new MetricsTimeVaryingRate("RpcQueueTime", re
Hi,
Did anyone else notice that the RPCMetrics are supposed to export four
internal values:
public MetricsTimeVaryingRate rpcQueueTime =
new MetricsTimeVaryingRate("RpcQueueTime", registry);
public MetricsTimeVaryingRate rpcProcessingTime =
new MetricsTimeVaryingRate("RpcP
36:48)
>
>
> Review request for hbase.
>
>
> Summary
> ---
>
> Simple change to initialize RPC metrics based on methods declared in RPC
> protocol interfaces: HMasterInterface, HMasterRegionInterface,
> HRegionInterface.
>
>
> This addresses bug HB
---
This is an automatically generated e-mail. To reply, visit:
http://review.cloudera.org/r/442/
---
Review request for hbase.
Summary
---
Simple change to initialize RPC
15 matches
Mail list logo
