问题描述
在此配置中： 64 Gb，16核，带有Cassandra 3.1的Linux CentOS
row_cache_size_in_mb现在设置为零（cassandra.yaml） 由于OS Page缓存用于缓存读取，因此似乎工作良好。
因此，增加这个数字是否有任何好处/风险（JVM堆） 与使用Linux页面缓存？
解决方法
行缓存仅用于显式启用行数据缓存的表，默认情况下不使用。行高速缓存通常仅用于大多数不经常更改的读取数据，否则，数据更改将导致无效的高速缓存数据和重新填充磁盘中的高速缓存条目而导致额外的性能开销。您可以在DataStax发布的“最佳做法”系列的GetTextLen()中阅读更多内容。
关于行缓存和Linux缓冲区缓存之间的关系-主要区别是行缓存保留了可能由多个SSTable组装的完整行，而缓冲区缓存保留了经常压缩的SSTable块和Cassandra将需要一次又一次地解压缩它们。另外，如果分区分散在多个SSTable上，那么Cassandra在读取行时将需要检查它们。
,所有有关工作量和应用程序查询模式的信息。
如果您的应用程序经常读取行的一小部分子集（热），并且每行都完整读取，启用此功能可以避免读取磁盘，从而带来显着的性能优势。有一些行高速缓存命中率JMX指标可以为您的应用程序负载提供行和键高速缓存大小之间的任何性能差异。
如果您尚未手动配置行缓存，则表说明应如下所示。
Default: { 'keys': 'ALL','rows_per_partition': 'NONE' }.
如果启用，则大小应与热子集上行数据及其列值的内存大小成比例。对于粗略的估计，请使用nodetool cfstats将行缓存大小（即缓存中的行数）乘以压缩行平均大小，然后求和。
尽管有一些可用的部分或完整的堆外实现类，但与任何内存分配一样，它也会对垃圾回收产生影响。来自Datastax docs：
row_cache_class_name
Default: disabled. note The classname of the row cache provider to use. Valid values: OHCProvider (fully off-heap) or SerializingCacheProvider (partially off-heap).
由于整个行都被缓存，因此可能很昂贵。要注意的一件事是，如果频繁从行缓存中清除行（大小设置得太小或行数据经常更改），则垃圾回收器肯定有更多工作要做。
底线：为了理想地使用行缓存，一小组行必须很热。当一次访问整行时，行缓存会带来好处。如果使用非堆实现，则堆的风险很小。最后，进行一些负载测试并捕获一些延迟指标，以确定最适合您的需求并足够的缓存大小。