[
https://issues.apache.org/jira/browse/CASSANDRA-18454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17869693#comment-17869693
]
Stefan Miklosovic commented on CASSANDRA-18454:
-----------------------------------------------
That should probably stay as it is for backward compatibility etc. We might
still expose that information via other means / other mbean method and under a
different method.
For example, take a look into class "FullQueryLoggerOptionsCompositeData" and
how to is used. There is an mbean method in StorageServiceMBean, called
"CompositeData getFullQueryLoggerOptions();" and in NodeProbe, there is this:
{code}
public FullQueryLoggerOptions getFullQueryLoggerOptions()
{
return
FullQueryLoggerOptionsCompositeData.fromCompositeData(ssProxy.getFullQueryLoggerOptions());
}
{code}
Also look into the implementation of GetFullQueryLog, it just presents that to
a user. Nothing else. No parsing of data etc ... Super simple and under one
mbean enpoint for everybody do ingest.
What we are doing right now in the patch is that we are literally cherr-picking
the information we want from various sources, manually parsing that, doing the
computations around that and so on. The work we do while parsing it for the
output will be used just for nodetool command, nobody else could just approach
one mbean method and gather all pre-processed information by one simple call.
We should change that.
> Enhance nodetool gcstats
> -------------------------
>
> Key: CASSANDRA-18454
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18454
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
> Reporter: Brad Schoening
> Assignee: Dhanush Ananthkar
> Priority: Normal
>
> Nodetool gcstats provides only a brief one line output of historical GC
> activity with Max, Total, Stdev, etc
> {noformat}
> % nodetool gcstats
> Interval (ms) Max GC Elapsed (ms)Total GC Elapsed (ms)Stdev GC Elapsed
> (ms) GC Reclaimed (MB) Collections Direct Memory Bytes
> 11979 0 0
> NaN 0 0 -1
> {noformat}
> 1. Performance of garbage collection is such an key part of Cassandra
> performance that it would be helpful to have more complete metrics with
> *gcstats* here. The MBean java.lang.GarbageCollector has recent statistic
> which could be added in events/second for:
> * GcThreadCount
> * Duration
> The current size of eden / survivor / old space and humongous allocations
> should be shown as well.
> The metrics show with jhsdb jmap would be very helpful as well, if they're
> available.
> [https://docs.oracle.com/en/java/javase/11/troubleshoot/diagnostic-tools.html#GUID-A69901EC-F87D-4B63-A8B7-DE8684AD4FF9]
> 2. Since physical memory is also a critical part of GC performance, it would
> be useful to report the following MBeans
> |[cassandra_os_free_memory_bytes|https://github.com/instaclustr/cassandra-exporter/wiki/Exported-Metrics#_cassandra_os_free_memory_bytes]|Amount
> of free physical memory available (as seen by the Cassandra JVM process).|
> |[cassandra_os_free_swap_bytes|https://github.com/instaclustr/cassandra-exporter/wiki/Exported-Metrics#_cassandra_os_free_swap_bytes]|Amount
> of free swap space available (as seen by the Cassandra JVM process).|
> |[cassandra_os_memory_bytes_total|https://github.com/instaclustr/cassandra-exporter/wiki/Exported-Metrics#_cassandra_os_memory_bytes_total]|Total
> physical memory available (as seen by the Cassandra JVM process).|
> |[cassandra_os_swap_bytes_total|https://github.com/instaclustr/cassandra-exporter/wiki/Exported-Metrics#_cassandra_os_swap_bytes_total]|Total
> swap space available (as seen by the Cassandra JVM process).|
> or use
> [/proc/meminfo|https://stackoverflow.com/questions/59581597/get-available-ram-in-java]
> SystemInfo.java already reads /proc/<pid>/limits on Linux systems.
> 3. Status of memlock
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
