Performance DSE-Cassandra：提交日志磁盘对性能的影响

我正在运行一个DSE 4.6.5集群（Cassandra 2.0.14.352）。 按照datastax的指导原则，在每台机器上，我都将数据目录与commitlog/saved caches目录分开：

• 数据存储在高速驱动器上
• 提交日志和保存的缓存位于系统驱动器上：2个HDD RAID1

使用OpsCenter监控磁盘在执行密集写入时，我发现第一个磁盘没有问题，但是从后面的（提交日志）中可以看到队列大小平均约为300到400，峰值高达700个请求。当然，这些驱动器上的延迟也相当高

这是否会影响群集的性能？ 您是否建议将提交日志和保存的缓存放在SSD上？与系统磁盘分离

谢谢

编辑-从以下节点之一添加tpstats：

[root@dbc4 ~]# nodetool tpstats
Pool Name                    Active   Pending      Completed   Blocked  All time blocked
ReadStage                         0         0          15938         0                 0
RequestResponseStage              0         0      154745533         0                 0
MutationStage                     1         0      306973172         0                 0
ReadRepairStage                   0         0            253         0                 0
ReplicateOnWriteStage             0         0              0         0                 0
GossipStage                       0         0         340298         0                 0
CacheCleanupExecutor              0         0              0         0                 0
MigrationStage                    0         0              0         0                 0
MemoryMeter                       1         1          36284         0                 0
FlushWriter                       0         0          23419         0               996
ValidationExecutor                0         0              0         0                 0
InternalResponseStage             0         0              0         0                 0
AntiEntropyStage                  0         0              0         0                 0
MemtablePostFlusher               0         0          27007         0                 0
MiscStage                         0         0              0         0                 0
PendingRangeCalculator            0         0              7         0                 0
CompactionExecutor                8        10           7400         0                 0
commitlog_archiver                0         0              0         0                 0
HintedHandoff                     0         1            222         0                 0

Message type           Dropped
RANGE_SLICE                  0
READ_REPAIR                  0
PAGED_RANGE                  0
BINARY                       0
READ                         0
MUTATION                 49547
_TRACE                       0
REQUEST_RESPONSE             0
COUNTER_MUTATION             0

编辑2-合成孔径雷达输出：

04:10:02 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
04:10:02 PM     all     22.25     26.33      1.93      0.48      0.00     49.02
04:20:01 PM     all     23.23     26.19      1.90      0.49      0.00     48.19
04:30:01 PM     all     23.71     26.44      1.90      0.49      0.00     47.45
04:40:01 PM     all     23.89     26.22      1.86      0.47      0.00     47.55
04:50:01 PM     all     23.58     26.13      1.88      0.53      0.00     47.88
Average:        all     21.60     26.12      1.71      0.56      0.00     50.01

在执行密集写入时使用Opscener监视磁盘，我发现第一个磁盘没有问题

Cassandra在内存（memtable）和commitlog（磁盘）上保存写操作

当memtable大小增长到阈值时，或者当您手动触发它时，Cassandra会将所有内容写入磁盘（刷新memtables）

要确保您的设置能够处理您的工作负载，请尝试手动刷新所有memtables

nodetool flush

在节点上。或者只是一个特定的键空间

nodetool flush [keyspace] [columnfamilfy]

同时监视磁盘I/O

如果I/O等待时间很长，则可以通过添加更多节点来共享工作负载，或者将数据驱动器切换到吞吐量更高的更好的驱动器

密切注意删除的突变（可能是发送写入/提示的其他节点）和删除的刷新写入程序

我从后面的（提交日志）中看到的队列大小平均约为300到400，峰值高达700个请求

这可能是您对commitlog的写入。 你的硬件还有其他功能吗？是软件raid吗？您是否已禁用交换

---

Cassandra单独工作效果最好：）所以是的，至少将commitlog放在一个单独的（可以更小）磁盘上。

谢谢你的回答。硬件是卡桑德拉专用的。手动刷新似乎很好，但无论如何，我已经在日志中看到很多刷新。关于CPU iowait，它的移动不多（约0.5%）。当负载更高时，我确实有时会看到一些关于突变的消息：

INFO[ScheduledTasks:1]2015-04-15 16:21:43229 MessagingService.java（第875行）349在过去5000毫秒内丢失的突变消息

我不确定这意味着什么……关于丢失突变的原因，请看一看。它将为您提供一个关于引发突变的事件以及监控内容的指南。确保跨客户端请求和Cassandra响应（例如，插入带有已删除突变的节点的日志的时间）