Alaine - Awesome information!!!
I had made some changes before seeing your email.
Current setup
CMS
16G heap
6G Eden
I also reduced Initiating Occupancy from 75 to 60. The thinking was that GC
will happen sooner giving me room for a burst to let GC catch up?? Maybe
that's completely wrong
2018-07-06 13:04 GMT+01:00 Simon Fontana Oscarsson <
simon.fontana.oscars...@ericsson.com>:
> Running nodetool status is okay if you want the simplest solution.
> But it generates a lot of output and creates a new JMX connection for
> every execution.
> Cassandra uses JMX to expose metrics via
Running nodetool status is okay if you want the simplest solution.
But it generates a lot of output and creates a new JMX connection for every
execution.
Cassandra uses JMX to expose metrics via mbeans.
Read this to get a first understanding:
Hi,
Thank you so much for answers.
Please, can you explain more what's metric libraries ? and give me some
examples ?
Using nodetool status, to generate the history of my data center, i intend
to proceed as follows:
>From a node A:
For i 1 ..24 hours (every 2 minutes do)
./nodetool status
>From the output you shared, it looks like you have at least one *very*
large partition — my guess is its lots of very small rows per partition.
This would explain why the slow compaction and why "nodetool stop
compaction" didn’t work (prior to CASSANDRA-14397 stop only works between
partitions).
