Cassandra 写入基准，低 (20%) CPU 使用率

Posted 2023-03-22

【中文标题】Cassandra 写入基准，低 (20%) CPU 使用率

【英文标题】：Cassandra write benchmark, low (20%) CPU usage

【发布时间】：2015-10-30 17:56:51

【问题描述】：

我正在 Amazon EC2 上构建 Cassandra 3x m1.large 集群。我使用 DataStax Auto-Clustering AMI 2.5.1-pv 和 Cassandra DataStax Community 版本 2.2.0-1。

在对“生产”数据进行写入基准测试时，集群似乎每秒可以处理大约 3k 到 5k 的写入请求，而没有读取负载。 几乎所有时间节点都这样做：

system.hints 的压缩 mykeyspace.mybigtable 的压缩 mybigtable 索引的压缩

但是，让我担心的是 CPU 使用率低。所有 3 个节点的 CPU 使用率都在 17% 到 24% 之间。 CPU使用率是不是太低了？这不是限制我的写入速度吗？对我来说可能是 100%。

顺便说一句。如何检查限制我写入性能的因素（CPU、内存、网络、磁盘）？

以下是一些统计数据：

编辑：

我正在插入分布在集群周围的数据 我使用的一致性级别为 One

【参考方案1】：

首先，CPU 不是 20%。当 CPU 系统为 20% 时，用户 CPU 为 70% 左右。下面是用户CPU和系统CPU的解释：User CPU time vs System CPU time?

其次，不带参数调用 iostat 并不是查看磁盘使用情况的最佳方式。来自：Basic I/O Monitoring on Linux

如果没有指定的时间间隔，iostat 会显示自 系统启动然后退出，这在我们的案例中没有用。

要更全面地了解系统，请使用

  dstat -rcdgilmnps 60

现在我们可以清楚地看到最后一分钟的平均值。 CPU 空闲率为 1-4%，我们有大约 340 个 ios 和 15M 写入速度。

下一个有用的工具是 nodetool cfstats：

我们可以在其中查看特定表格的一些统计信息。写入延迟统计数据特别有趣，等于 1.5 毫秒。

最后，执行写入跟踪：

id: 12345 -> host NodeAsked:9042, achieved consistency: LocalOne
Sending MUTATION message to /NodeA on NodeAsked[MessagingService-Outgoing-/NodeA] at 0
Sending MUTATION message to /NodeB on NodeAsked[MessagingService-Outgoing-/NodeB] at 0
REQUEST_RESPONSE message received from /NodeA on NodeAsked[MessagingService-Incoming-/NodeA] at 0
Processing response from /NodeA on NodeAsked[SharedPool-Worker-32] at 0
MUTATION message received from /NodeAsked on NodeA[MessagingService-Incoming-/NodeAsked] at 12
Determining replicas for mutation on NodeAsked[SharedPool-Worker-45] at 114
Appending to commitlog on NodeAsked[SharedPool-Worker-45] at 183
Adding to mytable memtable on NodeAsked[SharedPool-Worker-45] at 241
Appending to commitlog on NodeA[SharedPool-Worker-5] at 5360
Adding to mytable memtable on NodeA[SharedPool-Worker-5] at 5437
Enqueuing response to /NodeAsked on NodeA[SharedPool-Worker-5] at 5527
Sending REQUEST_RESPONSE message to /NodeAsked on NodeA[MessagingService-Outgoing-/NodeAsked] at 5739

表明限制我们的是存储速度。最好在正常写入负载上启用跟踪来执行多个自发写入以查看一些模式。

如果您同意，请投票。

【参考方案2】：

您用来进行基准测试的应用程序是否在任何地方都可用（开源）？如果您的应用程序正在执行诸如串行发送请求之类的操作，那么您的吞吐量可能会在超过集群实际限制的延迟（littles law）上成为瓶颈。 CPU 应该是写入性能的限制因素，因此 20% 确实有单线程应用程序关注它。

有一个工具 cassandra-stress 可以模拟大多数类型的负载，从而充分利用您的客户端。

【讨论】：

这是我的应用程序，它从 SQL DB 加载数据，对其进行转换并将其放入 SQL 中。它与业务非常耦合，所以很可能我不会开源它。但是，我已经测试了多种负载类型（又名压力测试和负载测试）。关于 cassandra-stress 的要点 - 我将尝试在星期一运行它。

值得一试，很多时候客户端在集群之前达到峰值

要在您的数据模型中使用 cassandra-stress，请尝试使用此工具 www.sestevez.com/sestevez/CASTableSizer/ www.datastax.com/dev/blog/improved-cassandra-2-1-stress-工具基准任何模式

Cassandra-stress 工具与我的架构显示出相同水平的性能。 CPU 也保持在同一水平。但是，我发现了其他东西 - 请稍后查看我的答案。

【参考方案3】：

这是一个一致性问题。当您插入数据并且一致性级别在您的情况下为 Quorum 时，驱动程序会等待所有节点响应数据可用，在插入时，执行一个一致性级别，这将为您提供更好的性能。 至于compaction的性能请看下面的文章：http://www.datastax.com/dev/blog/ec2-series-doc

写入性能不佳的另一个原因可能是表格设计。如果您没有设置正确的分区键（取决于您的数据），那么您可能会得到很长的行，通常在压缩时需要更长的时间。 如果您愿意，可以提供您的表模型（模式）和数据样本，以便更详细地回答这个问题。

还请记住，C* 旨在在商用硬件上运行。它很少充分利用系统资源，即可用处理器能力。然而，Cassandra 可以在读取时利用尽可能多的内存！ 至于写入吞吐量，有一个名为 CCM (https://github.com/pcmanus/ccm) 的工具可以对您的安装进行基准测试...

【讨论】：

感谢您的回答！我已经阅读了这些资源。但是，我不是在寻找“为什么这么慢”的解释，而是在寻找为什么 CPU 只有 20% 的解释？不应该更高吗？这不会产生更好的写入速度吗？

您机器的处理器不存储您的数据，存储系统是。因此，拥有高处理器使用率将是一件坏事，这意味着将在这个级别上做一些事情。谈到 Cassandra，一切都与您的存储性能有关，并且 - 在某些情况下调整您的节点集。一个好的起点在这里：academy.datastax.com 和特定的 DS201，它将为您提供有关可以调整的内容以及调整的场合的所有信息 :)

ccm 专为测试操作和功能而设计，不建议用于任何类型的基准测试

@pcdoc 可能意味着 cassandra-stress 工具。无论如何，iostat 显示使用率约为 1.4MB/s - 这对于 EC2 m1.large 来说应该不算多。