commit log的fsync提交延迟告警原因及解决方法咨询

我来帮你拆解这个Cassandra的commit log同步警告问题，先理清楚原因，再给你可行的修复方案：

1. 警告产生的原因 #

先看一下你遇到的警告内容：

WARN [PERIODIC-COMMIT-LOG-SYNCER] 2018-05-23 08:59:19,075 NoSpamLogger.java:94 - Out of 1 commit log syncs over the past 0s with average duration of 13038.00ms, 1 have exceeded the configured commit interval by an average of 3038.00ms

这个警告的核心逻辑很明确：系统尝试在你配置的commitlog_sync_period_in_ms时间窗口内完成commit log的fsync磁盘刷写操作，但实际单次fsync耗时（13038ms）已经超过了配置的同步间隔（13038-3038=10000ms，也就是10秒）。

具体导致这个问题的常见诱因有：

• 磁盘IO性能瓶颈：fsync是把内存中的commit log强制刷到磁盘的操作，如果磁盘本身读写速度慢（比如用HDD而非SSD）、磁盘IO负载过高（同时有大量读写请求），就会导致fsync耗时远超预期。
• 同步间隔配置过小：如果commitlog_sync_period_in_ms设置得太短，留给fsync完成的时间不足，哪怕磁盘性能正常，也可能出现超时。
• 高写负载导致commit log堆积：当集群写请求量过大时，短时间内会产生大量commit log数据，fsync需要刷写的数据量变大，自然耗时增加。
• 系统IO调度策略不合理：比如使用默认的CFQ（完全公平队列）调度器，对Cassandra这类随机IO密集型应用不够友好，会额外增加IO等待时间。

2. 问题修复方案 #

针对上面的原因，你可以尝试以下几种解决方案：

• 调整commit log同步间隔：
  适当调大commitlog_sync_period_in_ms的值，给fsync操作足够的完成时间。比如你当前配置的是10000ms（10秒），可以尝试调到15000ms或20000ms。修改cassandra.yaml后重启Cassandra生效：

  commitlog_sync: periodic
  commitlog_sync_period_in_ms: 15000
  

• 优化磁盘IO性能：

  • 用iostat -x 1或iotop工具检查磁盘的IO使用率（%util）、平均等待时间（await），如果%util接近100%或者await远高于20ms，说明磁盘已经饱和。
  • 优先把commit log目录迁移到单独的SSD磁盘上，和数据文件目录分开，减少IO资源竞争。
  • 条件允许的话，直接升级存储介质为SSD，大幅提升磁盘读写性能。

• 调整系统IO调度器：
  Cassandra推荐使用deadline或noop调度器，而非默认的CFQ。你可以临时修改调度器：

  echo deadline > /sys/block/sda/queue/scheduler
  

  要永久生效，可以在/etc/fstab中添加elevator=deadline参数，或者通过内核启动参数配置。

• 降低集群写负载：

  • 如果集群写压力过大，考虑扩容增加节点，分散写请求到更多节点上。
  • 在业务允许的前提下，降低写入的一致性级别（比如从QUORUM调整为LOCAL_QUORUM或ONE），减少节点间的同步开销。
  • 优化数据模型，避免不必要的重复写入，比如合并批量写入请求。

• 调整commit log总大小：
  检查commitlog_total_space_in_mb参数，如果设置太小，会导致commit log频繁滚动，增加fsync的频率。适当调大这个值（比如从默认的8192MB调到16384MB），减少滚动次数，降低fsync的压力。

内容的提问来源于stack exchange，提问作者Coder