暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

TiDB 磁盘 I/O 过高的确认办法

原创 wzf0072 2023-06-06
420

TiDB 磁盘 I/O 过高的确认办法


从 log 定位 I/O 问题

  • 如果客户端报 server is busy 错误,特别是 raftstore is busy 的错误信息,会和 I/O 有相关性。

    可以通过查看监控:grafana -> TiKV -> errors 监控确认具体 busy 原因。其中,server is busy 是 TiKV 自身的流控机制,TiKV 通过这种方式告知 tidb/ti-client 当前 TiKV 的压力过大,过一会儿再尝试。

  • TiKV RocksDB 日志出现 write stall

    可能是 level0 sst 太多导致 stall。可以添加参数 [rocksdb] max-sub-compactions = 2(或者 3) 加快 level0 sst 往下 compact 的速度,该参数的意思是将从 level0 到 level1 的 compaction 任务最多切成 max-sub-compactions 个子任务交给多线程并发执行。

    如果磁盘 I/O 能力持续跟不上写入,建议扩容。如果磁盘的吞吐达到了上限(例如 SATA SSD 的吞吐相对 NVME SSD 会低很多)导致 write stall,但是 CPU 资源又比较充足,可以尝试采用压缩率更高的压缩算法来缓解磁盘的压力,用 CPU 资源换磁盘资源。

    比如 default cf compaction 压力比较大时,可以调整参数 [rocksdb.defaultcf] compression-per-level = ["no", "no", "lz4", "lz4", "lz4", "zstd", "zstd"] 改成 compression-per-level = ["no", "no", "zstd", "zstd", "zstd", "zstd", "zstd"]

从告警发现 I/O 问题

集群部署工具 (TiUP) 默认部署的告警组件,官方已经预置了相关的告警项目和阈值,I/O 相关项包括:

  • TiKV_write_stall
  • TiKV_raft_log_lag
  • TiKV_async_request_snapshot_duration_seconds
  • TiKV_async_request_write_duration_seconds
  • TiKV_raft_append_log_duration_secs
  • TiKV_raft_apply_log_duration_secs
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论