Cassandra 2.0 中的高 CPU 使用率答案

【问题标题】：High CPU Usage in Cassandra 2.0Cassandra 2.0 中的高 CPU 使用率
【发布时间】：2017-01-02 16:34:55
【问题描述】：

运行 4 节点集群 cassandra 版本 2.0.9。最近自从一个一个月，我们看到所有节点上的 CPU 使用率大幅飙升。

tpstats 给了我很高的本地传输请求。附上截图对于 3 个节点 tpstats

节点 1 节点 2 节点 3

我应该从哪里开始调试？

此外，如果您从第一张图片中看到，当负载变高时，读取并且写变低。这是可以理解的，因为大多数请求丢弃

【问题讨论】：

您是否也看到了高 GC 暂停？您的 system.log 中有任何墓碑压倒性异常或批量大小警告吗？通常这种情况是由于错误的查询、错误的模型或滥用批处理语句造成的。
感谢 Aaron 的建议。是的，我们确实得到了墓碑压倒性异常（默认阈值 > 100000）。我们做了一些删除。有没有办法避免这个例外？我们是否应该将压缩时间更改为水平压缩（我们希望快速读取此表）。我们应该将 gc_grace_seconds 减少到 3 天吗？有没有办法可以监控哪些查询在服务器上运行缓慢？我们监控了 Native Transport Request 线程，发现它们占用了大量的 CPU 周期。我们可以查询与这些请求相关的查询吗？

标签： cassandra datastax cassandra-2.0 datastax-php-driver

【解决方案1】：

如何减轻墓碑？我可能每个月都会从我们的开发团队那里收到十几次这个问题。最简单的方法是不删除，我对此非常认真。否则，您可以以一种更好的方式减轻墓碑的方式为您的表建模。

例如，假设我有一个简单的表格来跟踪订单状态。由于一个订单可以有几种不同的状态（待处理、拣货、发货、接收、退回等），一种懒惰的方法是每个订单有一行，然后删除或运行就地更新来更改状态（取决于状态是否是您密钥的一部分）。更好的方法是将其转换为时间序列并通过 TTL 执行删除。该表看起来像这样：

CREATE TABLE orderStatus (orderid UUID,
    updateTime TIMEUUID,
    status TEXT,
    PRIMARY KEY (ordered, status))
with CLUSTERING ORDER BY (updateTime DESC);

假设我知道我真的只关心最多 30 天的订单状态，所以所有状态更新的 TTL 都是 30 天...

INSERT INTO orderStatus (orderid,updateTime,status) 
VALUES (UUID(),now(),'pending') USING TTL 2592000;

该表将支持按orderid 查询订单状态，按更新时间降序排序。这样，我可以从该表中选择一个 LIMIT 1 的 id，并始终获得最新状态。此外，这些状态将在 30 天后自动删除。现在，TTLing 数据仍然会创建墓碑。但是这些墓碑与新订单（我可能更关心的那些）是分开的，所以我通常不必担心那些墓碑会干扰我的查询（因为它们都分组在我不会的分区中经常查询）。

这是一个例子，但我希望减少墓碑建模背后的想法是明确的。主要的想法是对表进行分区，使墓碑与您最常查询的数据分开。

有什么方法可以让我们监控哪些查询在服务器上运行缓慢？

不，真的没有办法做到这一点。但是，您应该能够向您的开发人员请求所有关于问题键空间/表的查询。这应该很容易，因为一个表实际上应该只能支持一两个查询。如果您的开发人员构建了一个支持 5 或 6 个不同查询的表，那么他们做错了。

当您查看查询时，这些是您应该质疑的一些危险信号：

未绑定查询（不带 WHERE 子句的 SELECT）。
带有 ALLOW FILTERING 的查询。
二级索引的使用。
使用 IN。
使用 BATCH 语句（我之前看到过一个批处理语句翻转节点）。

【讨论】：