1

我正在 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、内存、网络、磁盘）？

以下是一些统计数据：

网络统计

tpstats

最佳

iostat

编辑：

  • 我正在插入很好地分布在集群周围的数据
  • 我正在使用一致性级别一
4

3 回答 3

4

首先，CPU 不是 20%。当 CPU 系统为 20% 时，用户 CPU 为 70% 左右。这是用户 CPU 和系统 CPU 之间的解释：用户 CPU 时间与系统 CPU 时间？

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

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

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

  dstat -rcdgilmnps 60

数据统计

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

下一个有用的工具是 nodetool cfstats： 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

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

如果您同意，请投票。

于 2015-08-10T14:32:07.540 回答
1

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

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

于 2015-08-07T14:11:22.557 回答
0

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

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

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

于 2015-08-07T13:22:20.597 回答