Cassandra 2.0中的高CPU使用率

运行4节点群集cassandra 2.0.9版。最近自从 本月，我们看到所有节点上的CPU使用量都出现了巨大的峰值

tpstats为我提供了很高的本机传输请求。附加屏幕截图 对于3节点tpstats

节点1 节点2 节点3

我应该从哪里开始调试

此外，如果您从第一张图片中看到，当负载变高时，读取 写的速度变慢了。这是可以理解的，因为大多数

---

请求下降

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

例如，假设我有一个简单的表来跟踪订单状态。由于订单可以有几种不同的状态（待定、提货、发货、接收、退回等），因此延迟的方法是每个订单有一行，然后删除或运行就地更新以更改状态（取决于状态是否是密钥的一部分）。更好的方法是将其转换为时间序列，并通过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

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

这是一个例子，但我希望墓碑缓解建模背后的想法是明确的。主要的想法是以这样一种方式对表进行分区，即墓碑与您最常查询的数据分开

有没有一种方法可以监控服务器上哪些查询运行缓慢

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

当您查看查询时，以下是您应该询问的一些危险信号：

• 未绑定查询（选择不带WHERE子句）
• 使用“允许筛选”的查询
• 二级索引的使用
• 在中使用
• 使用批处理语句（我以前见过一个批处理语句在节点上翻转）

---

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