한국어 English 日本語简体中文繁體中文 Deutsch ไทย Tiếng Việt Русский Português (Brasil)Español Bahasa Indonesia

ゲームスレッドの同期呼び出し Synchronous DB / file I/O on the game loop

原因ID sp-sync-call · 主担当 ゲーム開発チーム・サーバー開発

図と実験のあるメインページでこのカードを開く →

ティックの途中でDBの応答やファイルの書き込みを待つと、その時間だけサーバーのゲーム進行全体が止まります。

なぜティック内でDBの参照・保存、ログの書き込み、外部APIの呼び出しを待つ → すると DBに100msかかればティックも100ms止まる → 画面では DB・ディスクが遅くなるたびに、フィールド全体が一瞬止まる

症状: フリーズ, カクつき
要因: ストール
誰に起きるか: 特定の場所・チャンネル, サーバー全体
いつ: 特定の操作をしたとき, ときどきランダムに
担当: 主担当 ゲーム開発チーム・サーバー開発
ゲーム開発チームの対応: 遅い処理（DBの参照・保存、ログの書き込み、外部APIの呼び出し）はすべて非同期に回し、結果は次のティックで反映（タイムアウトを設けるだけでは、待っている間はやはり止まる）。
数値の目安: 同じデータセンター内のDBとの往復が0.5msでも、1ティックに100回呼べば50msです。20ティックのバジェットをそれだけで使い切ります。
グラフでは: 不定期なスパイク · サーバーのティック時間、DBクエリの遅延
確認箇所: ティック時間のグラフとDBクエリの遅延（slow query logなど）・ディスクの遅延を同じ時間軸に並べて確認。ティックのメトリクスがなければ、bccのoffcputime -pでゲームスレッドがどこで待っているか
該当する場合: ティックが跳ねた時刻とDB・ファイルの遅延が跳ねた時刻が重なり、ゲームスレッドの待ち時間がDB応答の受信・ファイル書き込みのコールスタックに集中している
該当しない場合: DB・ディスクの遅延が平常なのにティックが跳ねるなら、GC停止かロック競合の側
確認手段: ゲームサーバー・クライアントのログ・メトリクスが必要

出典

Designs, Lessons and Advice from Building Large Distributed Systems Google
LADIS 2009の基調講演（Jeff Dean）。同じデータセンター内の往復は約0.5ms（500,000ns）
ASP.NET Core Best Practices Microsoft
データアクセス・I/O・時間のかかる処理は非同期で呼び出す、同期のブロッキング呼び出しはスレッドプールの枯渇と応答の遅れを招く
Demonstrations of offcputime, the Linux eBPF/bcc version IO Visor
スレッドが止まってCPUを離れていた時間（off-CPU）をコールスタックごとに集計、-pでプロセスを指定

あわせて読みたい原因

同じ層：L9 サーバーのゲームプロセス

同じ症状（フリーズ）を起こすほかの層の原因

フレームタイムのスパイク L1 クライアントのゲームプロセス
クライアントのガベージコレクション L1 クライアントのゲームプロセス
メインスレッドでの同期ロード・シェーダーコンパイル L1 クライアントのゲームプロセス
ストレージが遅くアセットストリーミングが間に合わない L1 クライアントのゲームプロセス
ゲームのセキュリティモジュール（アンチチート）の検査 L1 クライアントのゲームプロセス
Wi-Fi ↔ LTE・5Gの切り替え L2 クライアントのOS・端末
クライアントのメモリ不足・スワップ L2 クライアントのOS・端末
ビデオメモリ（VRAM）不足 L2 クライアントのOS・端末

図と実験のあるメインページでこのカードを見る