使用Cassandra 1.1.5，一直在与慢速写入性能，JVM GC锁定，......在我们的日志中，我们经常看到这一点：
WARN [ScheduledTasks:1] 2013-08-28 09:28:51,983 GCInspector.java (line 145) Heap is 0.8589157615524839 full. You may need to reduce memtable and/or cache sizes. Cassandra will now flush up to the two largest memtables to free up memory. Adjust flush_largest_memtables_at threshold in cassandra.yaml if you don't want Cassandra to do this automatically
我们系统中最大的memtable（通过JConsole观察到）可以运行大约20,000,000个数据大小（我假设它是~20MB，如果这些是字节）。
如果重要，该列族中几乎有1B行。
flush_largest_memtables_at设置为0.75，但似乎我们几乎连续不断。该表的模式是大量写入，读取次数很少。 （基本上是一个集群日志）
禁用行缓存，密钥缓存设置为40MB。我们有8GB的堆与JVM相关联（24GB物理）。
堆的使用量大多在6.5到7.5GB之间。
建议在这里减少堆使用量？当然，这不是我们在集群中拥有多少数据的因素，是吗？ （我们在这个集群中有大量可用的磁盘）
答案 0 :(得分：3)
真正的解决方法是升级到1.2.x，其中bloom过滤器和压缩元数据已在堆外移动：http://www.datastax.com/dev/blog/performance-improvements-in-cassandra-1-2
答案 1 :(得分：1)
在1.1.x中看起来Bloom过滤器（随着每个节点中存储的数据量的增长而增长）保存在堆上。我们的单个ColumnFamily的-Filter.db文件超过1.6GB。
好文章：http://nmmm.nu/bloomfilter.htm
我们已经在此列家庭中修改了bloom_filter_fp_chance设置（这应该会减少布隆过滤器数据的大小），并且正在运行清理以查看会发生什么。
答案 2 :(得分：0)
我们在1.1中发现降低bloom_filter_fp_chance设置会有所帮助。如果你使用
nodetool cfstats
它有助于确定列系列的bloom过滤器大小对它有多大帮助。以读取时间为代价要考虑的另一件事是增加cassandra.yaml中的index_interval。如果你有很多小行，我会推荐这个。如果你有宽行，这可能不是一个好主意。
http://www.datastax.com/docs/1.1/configuration/node_configuration#index-interval
我建议采取堆转储并查看重型击球手的情况。