[
https://issues.apache.org/jira/browse/HBASE-20234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16427506#comment-16427506
]
Anastasia Braginsky commented on HBASE-20234:
---------------------------------------------
{quote}bq.Be careful on per-store counters. HBase is already crippled keeping
counts (one of the main users of CPU). The per-region counters are already
costly.
{quote}
I see. If we plan not to add any counter it would be quite difficult to keep
the metrics. Let's think we only want to keep a number of in-memory-flushes
that happened for a region. I can, for example, add a single per-region counter
that will be updated upon every in-memory-flush of any related store. However,
it will not save us too much CPU power. The CPU will be busy with contention on
updating a single "global" counter, where alternatively CPU will be busy with
updating "local" counters. With "global" counter you save some memory. The only
CPU power that is saved is the one that goes for collecting "local" counters
into "global" one. What do you think?
On a separate note, if HBase has so many counters, probably the big part of
them are AtomicInteger (for concurrency). The ingrementAndGet() method of
atomic integer is based on Compare-And-Swap (CAS) atomic hardware instruction.
This is not efficient, as CAS repeats in a while-loop till success. While an
alternative Fetch-And-Increment (F&I) atomic hardware instruction always
succeeds upon its first invocation. Bottom line, if you change this
implementation you save at least half of the CPU power that goes to those
increments all over the HBase... What do you think about that?
> Expose in-memory compaction metrics
> -----------------------------------
>
> Key: HBASE-20234
> URL: https://issues.apache.org/jira/browse/HBASE-20234
> Project: HBase
> Issue Type: Sub-task
> Reporter: stack
> Assignee: Anastasia Braginsky
> Priority: Major
>
> Hard to glean insight from how well in-memory compaction is doing currently.
> It dumps stats into the logs but better if they were available to a
> dashboard. This issue is about exposing a couple of helpful counts. There are
> already by-region metrics. We can add a few for in-memory compaction (Help me
> out [~anastas]... what counts would be best to expose).
> Flush related metrics include....
> {code}
> Namespace_default_table_tsdb-tree_region_cfbf23e7330a1a2bbde031f9583d3415_metric_flushesQueuedCount:
> {
> description: "Number flushes requested/queued for this region",
> value: 0
> {
> description: "The number of cells flushed to disk",
> value: 0
> },
> {
> description: "The total amount of data flushed to disk, in bytes",
> value: 0
> },
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
