1

使用 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 之间。

关于在这里减少堆使用的建议？当然，这不是我们在集群中有多少数据的一个因素，不是吗？（我们在这个集群中有大量可用的磁盘）

4

3 回答 3

3

真正的解决方法是升级到 1.2.x，其中布隆过滤器和压缩元数据已被移出堆：http ://www.datastax.com/dev/blog/performance-improvements-in-cassandra-1-2

于 2013-08-28T15:19:55.617 回答
1

看起来在 1.1.x 中，布隆过滤器（随着每个节点中存储的数据量而增长）被保存在堆上。我们的单个 ColumnFamily 的 -Filter.db 文件超过 1.6GB。

好文章： http: //nmmm.nu/bloomfilter.htm

我们已经bloom_filter_fp_chance在这个列族上向上修改了设置（这应该会减少布隆过滤器数据的大小），并且正在运行清理以查看会发生什么。

于 2013-08-28T15:10:40.600 回答
0

我们在 1.1 中发现降低 bloom_filter_fp_chance 设置会有所帮助。如果你使用

nodetool cfstats

它有助于确定它对列族的布隆过滤器大小有多大帮助。以读取时间为代价要考虑的另一件事是增加 cassandra.yaml 中的 index_interval。如果你有很多小行，我会推荐这个。如果您的行很宽，这可能不是一个好主意。

http://www.datastax.com/docs/1.1/configuration/node_configuration#index-interval

我建议进行堆转储并查看重击者是什么。

于 2013-08-29T02:33:03.090 回答