amazon-ec2 - Cassandra 内存不足(堆空间)

Question

最近我们正在对 Cassandra(版本 1.0.7)进行一些试验，我们似乎在内存方面遇到了一些问题。我们使用 EC2 作为我们的测试环境，我们有 3 个 3.7G 内存和 1 个核心 @ 2.4G 的节点，都运行 Ubuntu 服务器 11.10。

问题是我们从 Thrift 接口(interface)访问的节点会定期死掉(大约在我们存储 2-2.5G 数据之后)。错误消息:OutOfMemoryError: Java Heap Space 并且根据日志它实际上使用了所有分配的内存。

节点处于相对恒定的负载下，每分钟存储大约 2000-4000 个行键，这些行键通过 Trift 接口(interface)一次批处理 10-30 个行键(每个大约 50 列)。读取次数非常少，每天1000-2000左右，只请求单个row key的数据。目前只有一个使用的列族。

最初的想法是 cassandra-env.sh 文件中有问题。因此，我们根据节点的规范指定了变量“system_memory_in_mb”(3760)和“system_cpu_cores”(1)。我们还将“MAX_HEAP_SIZE”更改为 2G，将“HEAP_NEWSIZE”更改为 200M(我们认为第二个与垃圾收集有关)。不幸的是，这并没有解决问题，而且我们通过 thrift 访问的节点经常会死机。

如果您觉得这很有用，则关闭交换，并且所有 3 台服务器上的不可回收内存似乎都非常高(2.3GB，我们通常观察到其他 Linux 服务器上的不可回收内存量约为 0-16KB)(我们不太确定不可撤销的内存如何与 Cassandra 相关联，这只是我们在调查问题时观察到的)。 CPU 几乎一直处于空闲状态。根据nodetool，堆内存显然会偶尔减少一次，但随着时间的推移显然会超过限制。

有任何想法吗？提前致谢。

Answer 1

cassandra-env.sh 默认值几乎适用于所有工作负载，因此在您知道为什么会发生这种情况之前，最好将它们恢复为默认值，否则您可能会在不知不觉中使事情变得更糟。

我在我们的集群上看到了 2k/sec/node 的并发读写，因此每分钟 2k-4k 的写入非常少，尽管只有接受连接的节点正在死亡这一事实有点奇怪。

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

写的是什么样子的？
您是否重复编写相同的行键，如果是，您是追加新的列名还是覆盖相同的列名？
每次写多大？还有什么可以告诉我的吗？
如果您在同一行键中覆盖相同的列名，则不断压缩可能会很困难。
如果您不断地将新的列名附加到相同的行键，则您的行可能会变得太大而无法放入内存中。

垂死节点上的“nodetool -h localhost tpstats”的输出也可能会提供一些关于你跌倒的线索。任何不断悬而未决的事情都可能是坏消息，尤其是在如此低的写入率下。

如果您要在生产中使用 cassandra，您应该绘制内部图形以更好地了解正在发生的事情。 jmxtrans 和 Graphite 应该是你最好的新 friend 。