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

时间:2015-04-15 07:09:23

标签: performance cassandra datastax datastax-enterprise

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

1 个答案:

答案 0 :(得分:2)

  

在执行密集写入时使用OpsCenter监控磁盘,我发现第一个没有问题,

Cassandra坚持写入内存(memtable)和commitlog(磁盘)。

当记忆大小增加到阈值时,或者当您手动触发它时,Cassandra会将所有内容写入磁盘(刷新记忆库)。

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

nodetool flush
节点上的

。或者只是一个带

的特定键空间
nodetool flush [keyspace] [columnfamilfy]

同时监控磁盘I / O.

如果您有高I / O等待,您可以通过添加更多节点来共享工作负载,或者将数据驱动器切换到具有更高吞吐量的更好的数据驱动器。

密切关注丢失的突变(可以是发送写入/提示的其他节点)并删除了flush-writer。

  

我看到后来(提交日志)的队列大小平均大约为300到400,最多有700个请求。

这可能是您对commitlog的写入。 你的硬件是否适用于其他任何东西?它是软件突袭吗?你有交换禁用吗?

Cassandra最好的单独使用:)所以是的,至少,将commitlog放在一个单独的(可以更小的)磁盘上。