【发布时间】：2013-06-10 20:43:09
【问题描述】：
我浏览了 DataStax 文档，发现了一个有趣的声明。
它声称“插入繁重的工作负载在 Cassandra 中受 CPU 限制，然后才成为内存限制”。
有人可以解释一下这个声明是如何提出的吗？以及可能导致 Cassandra 这种行为的原因是什么？
谢谢。
【问题讨论】：
标签： cassandra datastax-enterprise
【发布时间】：2013-06-10 20:43:09
【问题描述】：
对于不同的工作负载，Cassandra 集群可以受 CPU、内存、I/O 或（有时）网络限制。文档中的说法是，如果您启动一个新集群并进行大量插入，则该集群最初会受到 CPU 限制，但过一段时间就会成为内存瓶颈。
为了处理插入，Cassandra 需要反序列化来自客户端的消息，找到应该存储数据的节点并将消息发送到这些节点。然后，这些节点将数据存储在称为 Memtable 的内存数据结构中。
最初这几乎总是受 CPU 限制。但是，随着更多数据的插入，memtable 会变大并刷新到磁盘并创建新的（空）memtable。刷新的 memtables 存储在称为 SSTables 的文件中。有一个称为压缩的持续后台进程，它将 SSTable 合并成越来越大的文件。
在此阶段更多内存会有所帮助的原因如下：
- 如果 Cassandra 堆空间不足，它会在内存表较小时刷新内存表。这会创建更小的 SSTable，因此需要做更多工作来压缩它们。
- 如果工作负载涉及在不同时间覆盖或插入同一行，如果该行仍在当前内存表中，这样做会便宜得多。如果不是，则覆盖和新列存储在新的内存表中，然后在压缩期间刷新和合并。同样，更少的内存意味着更多的压缩工作。
- 您的操作系统在压缩期间使用内存来缓冲读取和写入。如果操作系统不能，那么就会有额外的 I/O，从而减慢 memtable 刷新和压缩。
- 插入 Cassandra 会消耗大量 Java 对象，因此需要为垃圾收集器创建工作。如果堆太小，插入可能会在 GC 运行时暂停以产生一些空闲堆。 （另一方面，如果堆太大，插入可能会在 stop-the-world GC 期间暂停几秒钟。）
因此插入可能会受到内存限制，但它们也可能会受到 I/O 限制。如果没有足够的 I/O 来刷新内存表，那么一旦内存表刷新队列已满，插入操作就会被阻塞。所以我认为这个说法可能更准确一点：
大量插入工作负载在 Cassandra 中受 CPU 限制，然后才成为内存或 I/O 限制。
【讨论】：
-
感谢您的回复，但在我的场景中，我有一个 6 节点集群，每个集群都有一个四核 3GHz 处理器和 8GB 内存。在插入繁重的工作负载期间，我看到 CPU 利用率约为 80%，Cassandra 进程持续使用约 60%。我无法完全理解为什么 CPU 使用率如此之高？列的反序列化、分区和排序会消耗这么多 CPU 吗？对吞吐量有影响吗？如果对吞吐量有影响，您是否知道任何优化技术可以改善这一点？
-
你每秒插入多少次？是的，这种 CPU 使用率限制了您的吞吐量。如果您的工作量允许，您也许可以通过更大的批次来改进它。
-
谢谢，我会考虑批量突变选项，我能够达到大约 50000 次操作/秒，插入两个列族，其中一个是宽表。总有效载荷约为 100 字节。
-
如果您当前一次插入一列，批处理将产生重大影响。特别是如果您每行插入多列。
-
目前，单行多列进行批量突变。这是您的建议还是我通过某种方式将多行（每行多列）组合在一起以进行单个批量突变？