geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GEODE-7001) Add a gauge to track region entry count
Date Tue, 23 Jul 2019 16:52:00 GMT

    [ https://issues.apache.org/jira/browse/GEODE-7001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16891204#comment-16891204
] 

ASF subversion and git services commented on GEODE-7001:
--------------------------------------------------------

Commit 4e8ce22292c399f2754404eb473bc32dfad4d451 in geode's branch refs/heads/GEODE-7001-region-entry-count
from Michael Oleske
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=4e8ce22 ]

GEODE-7001:  Use LongAdder instead of AtomicLong

Co-authored-by: Michael Oleske <moleske@pivotal.io>
Co-authored-by: Dale Emery <demery@pivotal.io>


> Add a gauge to track region entry count
> ---------------------------------------
>
>                 Key: GEODE-7001
>                 URL: https://issues.apache.org/jira/browse/GEODE-7001
>             Project: Geode
>          Issue Type: New Feature
>          Components: statistics
>            Reporter: Dale Emery
>            Priority: Major
>          Time Spent: 40m
>  Remaining Estimate: 0h
>
> Add a gauge to RegionPerfStats to track the entry count.
> As part of understanding system state and health, knowing what regions exist with how
much data in them is an often asked question of a data store. The underlying metric is the
CachePerfStats.entries value. This is only a piece of the information that customers need
as it does not expose the region or region type to the users which is critical to understanding
how things are setup.
> Scenario: REPLICATE region
> Given a cluster with the following servers:
> - server1
> - server2
> And the cluster has a "REPLICATE" region named X
> And the user has put 10 entries with distinct keys into region X
> Then server1's meter registry has the following meter
> - meter name: member.region.entries
> - tag: region_name = X
> - tag: <all the common tags>
> - tag: data_policy = REPLICATE
> - value: 10
> Then server2's meter registry has the following meter
> - name: member.region.entries
> - tag: region_name = X
> - tag: <all the common tags>
> - tag: data_policy = REPLICATE
> - value: 10
> Scenario: PARTITION region with no redundancy
> Given a cluster with the following servers:
> - server1
> - server2
> And the cluster has a "PARTITION" region named X
> And the user has put 10 entries with distinct keys into region X
> Then server1's meter registry has the following meter
> - meter name: member.region.entries
> - tag: region_name = X
> - tag: <all the common tags>
> - tag: data_policy = PARTITION
> - value: between 0 and 10
> Then server2's meter registry has the following meter
> - name: member.region.entries
> - tag: region_name = X
> - tag: <all the common tags>
> - tag: data_policy = PARTITION
> - value: between 0 and 10
> And the values of those meters add up to 10
> Scenario: PARTITIONED REDUNDANT
> Given a cluster with the following servers:
> - server1
> - server2
> - server3
> And the cluster has a "PARTITION_REDUNDANT" region named X
> And the redundancy level is set to 1 copy (2 total copies of each key should exist)
> And the user has put 10 entries with distinct keys into region X
> Then server1's meter registry has the following meter
> - meter name: member.region.entries
> - tag: region_name = X
> - tag: <all the common tags>
> - tag: data_policy = PARTITION
> - value: between 0 and 10
> Then server2's meter registry has the following meter
> - name: member.region.entries
> - tag: region_name = X
> - tag: <all the common tags>
> - tag: data_policy = PARTITION
> - value: between 0 and 10
> Then server3's meter registry has the following meter
> - name: member.region.entries
> - tag: region_name = X
> - tag: <all the common tags>
> - tag: data_policy = PARTITION
> - value: between 0 and 10
> And the values of those meters add up to 20



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

Mime
View raw message