[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725664#comment-17725664
]
Stefan Miklosovic commented on CASSANDRA-18400:
-----------------------------------------------
My review is here https://github.com/apache/cassandra/pull/2362/commits
Couple things:
1) improved formatting
2) we do not say what metric was not found if it was not. There are cases in
NodeProbe where it is mentioned and other places where it is not. I fixed it
all as part of this ticket so we know what metric was not found. Good for
debugging purposes etc.
3) Registered alias for 3x in BufferPools is not necessary. There is actually a
ticket for this here (1) which is about removing what is there right now so
adding it here does not make sense. We can remove it in that other ticket.
4) I do not know why we are computing "size" as "size minus overflow size". I
think these metrics are independent. What is the logic behind the subtraction?
The documentation says this:
{code}
/**
* Total size, in bytes, of direct or heap buffers allocated by the pool
but not part of the pool
* either because they are too large to fit or because the pool has
exceeded its maximum limit or because it's
* on-heap allocation.
*/
public final Gauge<Long> overflowSize;
{code}
This is a valid metric, no? How I see it is that if this happens to overflow,
an operator knows that they should either increase the capacity so it fits in
or something is going on. If we believe this metric is always 0 then I do not
understand why we need the subtraction. I changed the output so it is included
so it looks like "size: n, overflow size: n, capacity: n".
(1) https://issues.apache.org/jira/browse/CASSANDRA-18313
> Nodetool info should report on the new networking cache
> -------------------------------------------------------
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
> Reporter: Brad Schoening
> Assignee: Ningzi Zhan
> Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png, Screen Shot
> 2023-05-19 at 12.59.46.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
