【发布时间】：2019-01-28 11:58:12
【问题描述】：
为了使用 Cassandra 获得更好的读取性能，我将行缓存设置从：
row_cache_size_in_mb = 0
收件人：
row_cache_size_in_mb = 2000
对于我的配置而言，行缓存的 2 GB 听起来很合理。于是，我重新启动了节点，我很惊讶这样的设置会降低我的整体性能 4 倍。例如，一个只需要 2 秒的查询，现在需要 8 多秒才能完成。
然后我启用了跟踪，我看到“行缓存命中”。我还看到行缓存命中率非常高。所以行缓存似乎可以与我的数据模型一起正常工作。但是，它显然会减慢我的查询速度...您知道为什么吗？
更新：
我做了一个新的测试。我保持行缓存：
row_cache_size_in_mb = 2000
我禁用了我拥有的最大列族（表）的行缓存：
'rows_per_partition': 'NONE'
现在我的查询像以前一样工作了（大约需要 2 秒）。那么，行缓存是否只是为了加快小型列族的查询？
对于大型列族，是否可以将数据推送到缓存中？我对大型 CF 的期望是，如果用户执行查询，然后如果它立即再次执行相同的查询，那么非第一个查询可以立即返回，因为行已经在内存中。
【问题讨论】：
-
你的堆有多大？你的 memtable 大小和 keycache 有多大？
-
我的堆大约是 16GB。每个节点的总内存为 48GB。密钥缓存和内存表设置变为默认值。您能否解释一下堆和行缓存之间的关系，因为据我所知，行缓存默认是堆外的？谢谢
-
您的 GC 日志是否报告了长时间的停顿？
grep "stopped: [1-9]" *gc*.current | grep `date +%m-%d`T | sort -nk11。 RowCacheKey 将分区键复制到新的字节数组中，因此当使用很多时，如果您有更大或复合键，它会给 YGC 带来很大压力。不相关：可能想将 memtable_heap_space_in_mb 设置为 1000。默认为 4gb 或 1/4 堆，这会产生很多碎片（如果使用默认 CMS）并且会导致大量刷新 - 这不是您的问题，但通常在堆时设置上限是个好主意变大。