[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838166#comment-17838166
]
Maxim Muzafarov commented on CASSANDRA-14572:
---------------------------------------------
[~maedhroz] Do you have a dump or any CI result links? The patch might increase
the heap usage a bit. While trying to keep the memory footprint low, it was
necessary to add the Map<String, Deque<MetricName>> to keep track of metric
alias names (they usually appear when a metric is renamed) and use them to
deregister the metrics when it's needed (e.g. a keyspace drop).
Due to the number of metrics, it may take some extra heap space, but shouldn't
be too much. My calculations and tests that I'd made showed that for each
metric we need ~ 10x8bytes for refs + some space for extra strings that
survive the eden gc ( e.g. ~10 symbols string 2 byte each x 6 fields) = 200
bytes for each metric. Considering 77k metrics in my tests above it will be ~
15Mb extra heap space (a JFR is attached in [the comment
above|https://issues.apache.org/jira/browse/CASSANDRA-14572?focusedCommentId=17809602&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17809602]
for the reference). I might be miscalculated something, of course.
We can create a new issue to fix that, and I'll try to find a solution for that.
As for the feature flag, I don't think it's necessary since the flag can't help
the way we handle metrics internally, plus a new keyspace and virtual tables
stand apart the core components. What we can do here in addition is to note in
the documentation that these new tables are experimental in the next upcoming
release.
> Expose all table metrics in virtual table
> -----------------------------------------
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
> Reporter: Chris Lohfink
> Assignee: Maxim Muzafarov
> Priority: Low
> Labels: virtual-tables
> Fix For: 5.1
>
> Attachments: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 7h 50m
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map<Text, Text> style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
