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

Question

我是运行 DSE 4.6.5 集群 (Cassandra 2.0.14.352)。按照 datastax 的指导方针，在每台机器上，我将数据目录与 commitlog/saved 缓存目录分开：

数据在超快的驱动器上
提交日志和保存的缓存在系统驱动器上：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 - sar 输出：

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

Answer 1

Monitoring disks with OpsCenter while performing intensive writes, I see no issue with the first,

Cassandra 持久写入内存（内存表）和提交日志（磁盘）。

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

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

nodetool flush

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

nodetool flush [keyspace] [columnfamilfy]

同时监控你的磁盘I/O。

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

密切关注丢弃的突变（可以是发送writes/hints的其他节点）和丢弃的flush-writer。

I see the queue size from the later (commit log) averaging around 300 to 400 with spikes up to 700 requests.

这可能是您对提交日志的写入。你的硬件服务于任何其他东西吗？是软件攻击吗？您是否禁用了交换？

Cassandra 单独工作时效果最好:)所以是的，至少将提交日志放在一个单独的（可以更小的）磁盘上。

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

DSE - Cassandra : Commit Log Disk Impact on Performances

performance

cassandra

datastax-enterprise

datastax