ゲームラグ白書 › L11 ディスク
サーバーの遅延ロード Lazy loading on the server
原因ID dk-lazy-load · 主担当 ゲーム開発チーム・サーバー開発 · 副担当 インフラチーム・サーバーインフラ
図と実験のあるメインページでこのカードを開く →
サーバーがダンジョン・マップのデータを初めて要求されたときにディスクから読むと、そのティックの間、全員が止まります。
なぜ 誰かが初めてダンジョン・エリアに入場 → すると サーバーがゲームスレッドでデータをディスクから読む → 画面では そのサーバーの全員が一瞬フリーズ
- 症状
- フリーズ
- 要因
- ストール
- 誰に起きるか
- 特定の場所・チャンネル, サーバー全体
- いつ
- 移動中・マップ切り替え時
- 担当
- 主担当 ゲーム開発チーム・サーバー開発 · 副担当 インフラチーム・サーバーインフラ
- ゲーム開発チームの対応
- サーバー起動時の事前ロード、非同期ロード。
- インフラチームの対応
- スナップショットから作ったばかりのサーバーは、サービス投入前にディスクのウォームアップ（全ブロックを一度読む）を行うか、高速スナップショット復元機能を使う。
- グラフでは
- 不定期なスパイク · サーバーのティック時間、ディスク読み込み
- 確認箇所
- 止まった時刻をゲームサーバーログのダンジョン・エリアへの初回入場の記録と突き合わせ、その瞬間のゲームサーバーのディスク読み込み（pidstat -dのkB_rd/s）と、perf trace --durationで長くかかったread・open呼び出しを確認。新しく立ち上がったクラウドサーバーなら、EBSのVolumeAvgReadLatencyを古いサーバーと比較
- 該当する場合
- 初めて入場した瞬間だけ止まり、同じ場所に2回目に入るときは止まらない。止まっている間、ゲームスレッドがファイルの読み込みで待っている
- 該当しない場合
- すでにロード済みのエリアでも同じように止まるなら、ティックバジェット超過・GCなど別の原因
- 確認手段
- ゲームサーバー・クライアントのログ・メトリクスが必要
- もっと詳しく
- クラウドでスナップショット（ディスクのコピー）から作ったばかりのサーバーは、初めて読むブロックごとにリモートストレージから取得するため、普段よりはるかに遅くなります。オートスケーリングで新しく立ち上がったサーバーでだけ最初の入場が際立って長くかかるなら、これを疑います。
出典
- Initialize Amazon EBS volumes AWS
スナップショットから作ったボリュームは、ブロックをS3から取得している間は遅延が増えて性能が落ちる、dd・fioで全ブロックを読んで事前に初期化 - Amazon EBS fast snapshot restore AWS
高速スナップショット復元は、作成時から初期化済みのボリュームを提供し、初回アクセスの遅延をなくす - pidstat(1) — Linux manual page sysstat
-d：プロセスごとのkB_rd/s（1秒あたりのディスク読み込み量） - perf-trace(1) — Linux manual page perf
--durationで指定したmsより長くかかったシステムコールだけを表示 - Amazon CloudWatch metrics for Amazon EBS AWS
VolumeAvgReadLatency：1分平均の読み込み遅延（Nitroインスタンス）
あわせて読みたい原因
同じ層：L11 ディスク
同じ症状（フリーズ）を起こすほかの層の原因
図と実験のあるメインページでこのカードを見る