ゲームラグ白書 › L11 ディスク
fsyncの集中 fsync storms
原因ID dk-fsync · 主担当 ゲーム開発チーム・サーバー開発 · 副担当 インフラチーム・サーバーインフラ, インフラチーム・DBインフラ
図と実験のあるメインページでこのカードを開く →
データを「確実に」ディスクに書き込むよう要求すると、ディスクによっては1回に0.1ms〜数十msかかり、要求が集中するとキューが長くなります。
なぜ 定期保存・ログアウトラッシュで確実な書き込みの要求が集中 → すると ディスクのキューが長くなる → 画面では 保存のタイミングごとにラグ、ログアウト・チャンネル移動の遅延
- 症状
- カクつき, 入力遅延
- 要因
- ストール, 遅延
- 誰に起きるか
- サーバー全体
- いつ
- 一定の周期で, 人が集中したとき
- 担当
- 主担当 ゲーム開発チーム・サーバー開発 · 副担当 インフラチーム・サーバーインフラ, インフラチーム・DBインフラ
- ゲーム開発チームの対応
- 保存をまとめて一度に（複数の保存を1回のfsyncで）、保存時刻の分散。
- インフラチームの対応
- サーバー機器・OS：電源保護機能のあるサーバー向けSSD、ディスクのキュー長・fsync遅延の監視。DBサーバー：保存先がDBなら、DBのログディスクも同様のSSDに、コミット遅延の監視。
- 数値の目安
- 1回にかかる時間は機器によって異なりますが、おおよそサーバー向けSSD（電源保護機能付き）で0.1ms、一般的なSSDで1〜数ms、クラウドディスクで1〜2ms、HDDで10ms以上です。1つのスレッドが1回ずつ待つと、HDDでは1秒に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）の遅延は1桁ms台、io2 Block Expressは16KiBのI/Oで平均500µs未満 - Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote) Google
HDDのシーク1回で10ms - 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 ディスク
同じ症状（カクつき）を起こすほかの層の原因
図と実験のあるメインページでこのカードを見る