Cassandra 3.11.6集群nodetool info返回NaN值问题求助

Hey，我来帮你拆解下你遇到的问题，其实这些NaN大多是有明确原因的，咱们逐个来看：

1. Row Cache和Counter Cache的NaN recent hit rate #

这个完全是正常现象，不用慌：

• 你看输出里这两个缓存的hits和requests都是0，命中率的计算逻辑是命中次数 / 请求次数，0除以0在数学上就是NaN嘛。
• 再看细节：Row Cache的capacity是0 bytes，说明你根本没开启Row Cache（默认就是关闭的，要手动在cassandra.yaml里设置row_cache_size_in_mb才会启用）；Counter Cache虽然开了25MiB的容量，但你的集群里目前没有Counter类型的数据读写，自然没有请求产生，所以出现NaN是预期内的。

2. Chunk Cache的NaN microseconds miss latency #

这个情况分两种可能：

临时统计未初始化 #

Chunk Cache的延迟统计需要积累一定数量的miss请求才会开始计算，你现在只有259次miss，可能系统还没完成采样，属于临时状态。你可以过个十几分钟再跑一次nodetool info，大概率会显示具体的延迟数值。

版本相关的小bug #

Cassandra 3.11.6确实存在一些Chunk Cache统计的小问题，比如当miss次数较少时，统计逻辑可能触发除以0的场景（比如计算平均延迟时某些中间值为0）。你可以试试这些操作：

• 执行nodetool clearsnapshot清理一下快照（如果有大量快照可能干扰缓存行为），然后重启节点观察是否恢复。
• 检查下集群负载，如果是测试环境或者低业务量的生产环境，miss操作太少导致统计模块生成不了有效数据，也会返回NaN，这种属于低负载下的正常表现。

额外排查建议 #

• 去看看Cassandra的system.log，有没有关于缓存初始化、内存分配的报错，如果有异常日志，直接针对报错处理就行。
• 如果是生产环境且业务量正常但NaN一直存在，可以考虑升级到3.11.x的后续小版本（比如3.11.14），后续版本修复了不少缓存统计的小问题。

内容的提问来源于stack exchange，提问作者Akilan M