2012-04-03 30 views
4

我们尝试了一下与卡桑德拉最近(1.0.7版本),我们似乎有一些问题的内存。我们使用EC2作为测试环境,我们有三个节点,内存3.7G,核心2.4G,全部运行Ubuntu 11.10。卡桑德拉运行内存(堆空间)

的问题是,我们从旧货接口击中节点定期死亡(约后,我们存储数据的2-2.5G)。错误消息:OutOfMemoryError:Java堆空间并根据日志实际上使用了所有分配的内存。

的节点是相对恒定的载荷下和存储关于2000-4000行键一分钟,这是通过在10-30行键的TRIFT接口一次分批(每个约50列)。读取次数非常低,每天约1000-2000次,只需要一个单一行密钥的数据。目前只有一个使用过的列族。

最初的想法是cassandra-env.sh文件中出现错误。所以,我们根据节点的规范指定了变量'system_memory_in_mb'(3760)和'system_cpu_cores'(1)。我们还将'MAX_HEAP_SIZE'更改为2G,将'HEAP_NEWSIZE'更改为200M(我们认为第二个与垃圾收集相关)。不幸的是,这并没有解决问题,我们通过节俭击中的节点不断定期死亡。

如果你觉得这个有用,交换关闭,所有3台服务器上的不可修复内存似乎非常高(2.3GB,我们通常会观察其他Linux服务器上的不可修复内存量约为0-16KB)不太清楚不可预测的记忆如何与Cassandra联系起来,它只是我们在观察问题时观察到的)。 CPU在整个时间都非常空闲。随着时间的推移,堆内存显然会逐渐减少,但显然随着时间的推移而增长。

任何想法?提前致谢。

+0

你在运行什么版本的Cassandra?另外,您可以将其发布到Cassandra用户列表中,因为它是获得有关此类事情建议的非常活跃的地方。 – dmcnelis 2012-04-03 14:25:59

+0

感谢您的评论。它是1.0.7。我更新了问题以显示我们正在运行的Cassandra的版本。我也将搜索Cassandra用户列表。谢谢。 – Bill 2012-04-04 12:06:09

+0

你是否启用缓存?行缓存可以真正杀死你的内存。另外,您是否手动指定提交日志阈值或更改cassandra.yaml中的任何内存内容? – Zanson 2012-04-09 23:47:42

回答

3

cassandra-env.sh默认是完美的几乎所有工作负载,所以直到你知道为什么发生这种情况最好把他们带回自己的缺省设置,也可能使事情变得更糟而不自知。

我在集群上看到了2k/sec /节点的并发读写,所以每分钟2k-4k写入的数据非常少,尽管它只是节点接受你正在死亡的连接,这有点奇怪。

如果您的应用程序连接到其他节点的一个节俭的端点是那么一个死?
客户端连接使用内存,因此可能值得仔细检查一次没有连接太多。在临死的cassandra节点上的“netstat -A inet | grep 9160”应该告诉你有多少个客户端连接。很大程度上取决于你的应用程序,你会期望10或100s而不是1000s。

写道是什么样子?
你是否重复写入相同的行键,如果是的话,你是追加新的列名还是覆盖相同的?
每次写入有多大?还有什么可以告诉我的吗?
如果您覆盖相同行键中相同的列名称,不断压缩可能会很困难。 如果您不断追加新的列名到相同的行键,您可能会增加行数太大而无法放入内存。

的“nodetool -h本地主机tpstats”垂死的节点上的输出也可以提供一些线索,你跌倒哪里。一直在等待的事情可能是个坏消息,尤其是在这么低的写入速度下。

如果您要在生产中使用cassandra,您应该绘制内部图形以更好地理解发生了什么。 jmxtrans和石墨应该是你最好的朋友。

+0

您可以通过问题分享用例describeb的几个关键设置吗? – 2013-04-05 16:40:05

2

有一些事情你可以尝试调整。首先确保你的列家族没有行缓存。同样值得一提的是,检查日志中的错误和tpstats会导致某些事件因错误而死亡,并且某些事情正在队列中备份。异常的堆栈跟踪也可能有意义,因为实际上有不同类型的OOM可能意味着内核调整。

如果您只是为每个节点使用太多的内存,那么您希望查看数据集的大小,请尝试检查cfstats,您可以大致确定在bloom过滤器上花费了多少空间。由于CF中有更多行,因此可以线性增大,并且是节点所需的基本最小内存的一部分。

nodetool cfstats | grep Bloom.*Used | awk '{ SUM += $5} END { print SUM " bytes" }' 

既然你不经常阅读,你可能会增加他们的误报率。每个SSTable都有一个bloom过滤器用来检查一行是否存在于其中。你可以用cqlsh

ALTER TABLE MyColumnFamily WITH bloom_filter_fp_chance = 0.1; 

改变后调用升级对CF(这将是缓慢的)每个节点

nodetool upgradesstables MyKeyspace MyColumnFamily 

有后果,这哪里读,因为有一个10可能需要较长时间%-ish(.1)的机会,它将检查SSTables中不存在的行,从而导致额外的磁盘搜索。

如果您有大量行的列族,则另一个主要的存储区是索引的采样率。这可以为每个节点级别的cassandra.yaml

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

如果您有它成立了以堆转储上OOM被修改(-XX:+ HeapDumpOnOutOfMemoryError在默认情况下,我相信)应该有一些堆转储在/ var/lib/cassandra/data目录中。你可以用visualvm或者任何你喜欢的工具打开它们来确定堆的哪一部分是在哪里。

+0

更新为Cassandra 2.0:'nodetool cfstats | grep“Bloom。* used”| awk'{SUM + = $ 6} END {print SUM“bytes”}'' – 2013-11-16 22:07:30