Question

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

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

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

但是在我们执行负载测试后，虽然我们还原了我们的更改，但我们开始经常遇到OOM和VM崩溃，比如每周2次。

我的问题是，有人知道卡桑德拉为什么会这样做？似乎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（因此没有墓碑），而且它是一个写密集型系统。

Answer 1

这并不足以弄清楚OOM造成了什么。通常你应该从你的数据模型开始，然后是jvm.options和cassandra.yaml，并弄清楚最新情况。与默认值相比有什么不同？

另一方面，从3.9开始，就像你的生活取决于它一样。一旦你开始修复就会有一个很糟糕的错误，打开文件句柄，几乎每次都会崩溃。

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

卡桑德拉OOM崩溃

1 个答案: