Cassandra OOM 崩溃

Posted 2023-04-18

【中文标题】Cassandra OOM 崩溃

【英文标题】：Cassandra OOM crash

【发布时间】：2017-12-08 07:01:10

【问题描述】：

我知道有很多 Cassandra 和 OOM 相关的问题，但这与它们有点不同。

我们公司有一个产品测试环境，在 Cassandra 3.9 上运行，处于 beta 阶段。此环境在单个节点上运行，具有 4 个 vCPU 和 8GB RAM。 5 个月来，这个环境一直定期输入数据，一天大约 40k 行，没有一个 OOM。

几周前，我们决定加载更多数据以查看我们的测试环境的限制，并在几个小时内插入了大约 50 万行。结果Cassandra因为OOM而崩溃了。之后，我们删除了 500k 行，应用程序再次恢复每天输入 40k 行。

但在我们执行负载测试后，虽然我们恢复了更改，但我们开始经常遇到 OOM 和 VM 崩溃，例如一周 2 次。

我的问题是，有人知道 Cassandra 为什么会这样吗？似乎 Cassandra 以某种方式扩展了它的限制，并且需要比以前更多的内存。

更新

数据模型中有几个表，但这是其中主要的两个，具有 80%-90% 的读/写：

CREATE TABLE global_events (
    customer_id bigint,
    start_dt timestamp,
    client_id text,
    connected boolean,
    site_id bigint,
    exit boolean,
    is_new boolean,
    is_visitor boolean,
    last_seen timestamp,
    PRIMARY KEY (customer_id, start_dt, client_id)
);
CREATE INDEX global_events_connected_idx ON global_events (connected);
CREATE INDEX global_events_site_id_idx ON global_events (site_id);
CREATE INDEX global_events_exit_idx ON global_events (exit);
CREATE INDEX global_events_is_new_idx ON global_events (is_new);
CREATE INDEX global_events_is_visitor_idx ON global_events (is_visitor);

CREATE TABLE local_events (
    customer_id bigint,
    local_id bigint,
    start_dt timestamp,
    client_id text,
    connected boolean,
    exit boolean,
    is_new boolean,
    is_visitor boolean,
    last_seen timestamp,
    PRIMARY KEY ((customer_id, local_id), start_dt, client_id)
);
CREATE INDEX local_events_connected_idx ON local_events (connected);
CREATE INDEX local_events_is_new_idx ON local_events (is_new);
CREATE INDEX local_events_is_visitor_idx ON local_events (is_visitor);

这些表中没有 TTL（因此没有墓碑），而且它是一个写入密集型系统。

【问题讨论】：

你的数据模型是什么？我猜如果你继续追加到相同的分区，索引开销将是问题。

检查您的 cassandra.yaml 设置，看看是否有任何缓存设置造成内存紧张。

@ChrisLohfink 添加数据模型

@GangadharKairi 你有什么设置会导致这种效果吗？

@serdar 设置，如 key_cache_size_in_mb 和 row_cache_size_in_mb 等。

【参考方案1】：

这些信息不足以找出 OOM 导致的原因。通常你应该从你的数据模型开始，然后是 jvm.options 和 cassandra.yaml 并弄清楚发生了什么。与默认值相比有什么不同？

另一方面，从 3.9 开始运行，就像你的生活依赖它一样。一旦您开始修复，打开文件句柄就会出现一个很棒的错误，并且几乎每次都会崩溃。

我的建议是更新到 3.11 并使用默认配置，然后看看它的行为。

【讨论】：

感谢您的回答，我会试一试。顺便问一下，你能提供一个 3.9 错误的链接吗？