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

Question

我正在 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

Answer 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

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

如果您同意，请投票。

Answer 2

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

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

Answer 3

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

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

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