【发布时间】：2019-10-23 04:01:04
【问题描述】：
我的 Cassandra 应用程序主要需要计数器写入和读取。因此，拥有计数器缓存对性能很重要。我将 cassandra.yaml 中的计数器缓存大小从 1000 增加到 3500，并重新启动了 cassandra 服务。结果不是我所期望的。磁盘使用率上升了，吞吐量下降了，根据我在 nodetool 信息中看到的内容，似乎计数器缓存根本没有被使用（见下文）。现在已经快两个小时了，性能还是很差。
昨天当我将计数器缓存从 0 增加到 1000 时，我看到了同样的模式。它有一段时间根本没有使用计数器缓存，然后由于某种原因它开始使用它。我的问题是我是否需要做一些事情来激活计数器缓存利用率？
这是我在 cassandra.yaml 中针对计数器缓存的设置：
counter_cache_size_in_mb: 3500
counter_cache_save_period: 7200
counter_cache_keys_to_save: (currently left unset)
这是我在大约 90 分钟后从 nodetool 信息中得到的信息：
Gossip active : true
Thrift active : false
Native Transport active: false
Load : 1.64 TiB
Generation No : 1559914322
Uptime (seconds) : 6869
Heap Memory (MB) : 15796.00 / 20480.00
Off Heap Memory (MB) : 1265.64
Data Center : WDC07
Rack : R10
Exceptions : 0
Key Cache : entries 1345871, size 1.79 GiB, capacity 1.95 GiB, 67936405 hits, 83407954 requests, 0.815 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 5294462, size 778.34 MiB, capacity 3.42 GiB, 0 hits, 0 requests, NaN recent hit rate, 7200 save period in seconds
Chunk Cache : entries 24064, size 1.47 GiB, capacity 1.47 GiB, 65602315 misses, 83689310 requests, 0.216 recent hit rate, 3968.677 microseconds miss latency
Percent Repaired : 8.561186035383143%
Token : (invoke with -T/--tokens to see all 256 tokens)
这是增加大小之前计数器缓存上的 nodetool 信息：
Counter Cache : entries 6802239, size 1000 MiB, capacity 1000 MiB,
57154988 hits, 435820358 requests, 0.131 recent hit rate,
7200 save period in seconds
更新： 我已经运行了几天，现在尝试在各个节点上尝试各种计数器缓存大小的值。计数器缓存在达到容量之前不会启用是一致的。据我所知，这就是它的工作原理。如果有人知道在缓存满之前启用缓存的方法，请告诉我。我将它设置得非常高，因为它看起来是最优的，但这意味着缓存会在它填满时关闭几个小时，而当它关闭时，我的磁盘绝对会因读取请求而被最大化......
另一个更新： 进一步运行表明，有时计数器缓存在填满之前确实会启动。我真的不知道为什么会这样。我还没有看到模式。我很想知道什么时候有效和无效的标准。
最后一次更新： 当计数器缓存填满时，节点的本地传输也被禁用。将计数器设置为 3.5 GB 我现在将在节点处于这种低性能状态并禁用本机传输的情况下运行 24 小时。
【问题讨论】：
标签： database-performance cassandra-3.0