游戏卡顿白皮书 › L11 磁盘
fsync 风暴 fsync storms
原因 ID dk-fsync · 主责 研发团队·服务器开发 · 配合 运维团队·系统运维, 运维团队·数据库运维
在含图示和实验的完整版中打开此卡片 →
要求把数据“真正”写进磁盘（确保落盘）时，视磁盘不同每次要花 0.1 ms 到几十 ms；请求一集中，队列就会变长。
起因 定时存盘、集中下线让确保落盘的写入请求扎堆 → 结果 磁盘队列变长 → 画面表现 每到存盘时间就卡，下线、换线变慢
- 症状
- 一卡一卡, 操作延迟
- 因素
- 停顿, 延迟
- 谁会遇到
- 全服
- 何时出现
- 固定周期, 人多的时候
- 负责方
- 主责 研发团队·服务器开发 · 配合 运维团队·系统运维, 运维团队·数据库运维
- 研发团队要做的事
- 合并存盘（多次存盘只做一次 fsync），错开存盘时间。
- 运维团队要做的事
- 服务器/OS：使用带掉电保护的服务器级 SSD，监控磁盘队列长度和 fsync 延迟。DB 服务器：存盘写到 DB 时，DB 日志盘也用同样的 SSD，监控提交延迟。
- 数值参考
- 单次耗时因硬件而异，大致为：服务器级 SSD（带掉电保护）0.1 ms，普通 SSD 1 到几 ms，云盘 1~2 ms，HDD 10 ms 以上。如果一个线程逐个等待，HDD 每秒连 100 次都做不到。
- 监控图上
- 周期性尖峰 · 磁盘队列长度、刷盘/写入延迟
- 查看位置
- 把 iostat -x 1 的 f/s、f_await（磁盘处理的刷盘次数及耗时）以及 w/s、aqu-sz、w_await 与定时存盘、下线时间叠加对照。旧版 sysstat 把 aqu-sz 显示为 avgqu-sz。云盘看 EBS 的 VolumeQueueLength、VolumeAvgWriteLatency
- 确认依据
- 每到存盘时间或集中下线时，刷盘次数和队列长度一起飙升，w_await、f_await 变成平时的几倍。此时存盘、换线变慢
- 排除依据
- 队列在与存盘、下线无关的时间飙升，看“备份/压缩/扫描任务”（dk-backup）或“IOPS 上限/队列饱和”（dk-iops）。刷盘次数不变却变慢，看“云盘突发积分耗尽”（dk-burst）
- 确认手段
- 运维工具即可确认（无需游戏代码）
出处
- fsync(2) — Linux manual page Linux man-pages
fsync 连磁盘缓存也一并刷出，并阻塞到设备报告完成 - Reliability (PostgreSQL Documentation) PostgreSQL
普通 SATA 磁盘和很多 SSD 带有断电即丢失的写缓存，要确保落盘，需要有电池或掉电保护的缓存 - Amazon EBS General Purpose SSD volumes AWS
云上默认磁盘（gp3）延迟为个位数 ms，io2 Block Express 的 16 KiB I/O 平均不到 500 µs - Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote) Google
HDD 一次寻道 10 ms - iostat(1) — Linux manual page sysstat
-x：f/s、f_await（磁盘处理的刷盘请求数及平均耗时），w/s，w_await，aqu-sz（旧名 avgqu-sz） - Amazon CloudWatch metrics for Amazon EBS AWS
VolumeQueueLength（等待完成的请求数），VolumeAvgWriteLatency（1 分钟平均写入延迟，Nitro 实例）
相关原因
同一层：L11 磁盘
其他层中同样导致“一卡一卡”的原因
查看含图示和实验的原卡片