【问题标题】:DSE - Cassandra : Commit Log Disk Impact on PerformancesDSE - Cassandra:提交日志磁盘对性能的影响
【发布时间】:2015-06-21 00:44:37
【问题描述】:

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

【问题讨论】:

    标签: performance cassandra datastax datastax-enterprise


    【解决方案1】:

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

    Cassandra 将写入持久化在内存(memtable)和提交日志(磁盘)中。

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

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

    nodetool flush
    

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

    nodetool flush [keyspace] [columnfamilfy]
    

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

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

    留意丢弃的突变(可以是发送写入/提示的其他节点)和丢弃的flush-writer。

    我看到后面的队列大小(提交日志)平均在 300 到 400 左右,峰值高达 700 个请求。

    这可能是您对提交日志的写入。 您的硬件是否有其他用途?是软件突袭吗?您是否禁用了交换?

    Cassandra 单独工作最好 :) 所以是的,至少将提交日志放在单独的(可以更小)磁盘上。

    【讨论】:

    • 感谢您的回答。硬件专用于 cassandra。手动刷新似乎工作正常,但无论如何我已经在日志中看到很多刷新。关于 CPU iowait,它不会移动太多(大约 0.5 %)。当负载较高时,我有时确实会看到一些关于突变的消息:INFO [ScheduledTasks:1] 2015-04-15 16:21:43,229 MessagingService.java (line 875) 349 MUTATION messages dropped in last 5000ms 我不确定这意味着什么......
    • 关于丢弃突变的原因,请查看link。它将为您提供有关引发突变的事件和监控内容的指南。确保将客户端请求与 Cassandra 响应交叉(例如,插入带有已删除突变的节点的日志的时间)
    猜你喜欢
    • 1970-01-01
    • 2015-10-22
    • 1970-01-01
    • 2014-09-18
    • 1970-01-01
    • 2016-11-25
    • 1970-01-01
    • 1970-01-01
    • 2015-01-20
    相关资源
    最近更新 更多