ゲームラグ白書 › 症状から探す
フリーズ：原因67件と担当
別名：固まる、止まる、応答なし
図のあるメインページの症状辞典で開く →
画面内のすべてが少しの間（0.5秒〜数秒）止まってから、また動き出します。
全員が静止。自分のキャラクターだけが予測で少し動くか、その場で走り続ける。再び動き出すと、たまっていた動きが早送りやワープになって一気に追いついてきます。
サーバーが丸ごと止まったか（GC、デッドロック、同期呼び出し）、回線が一瞬切れたか、自分のPCが止まりました。
この症状を引き起こす原因
L1 クライアントのゲームプロセス
- フレームタイムのスパイク: 1フレームの計算に普段の数倍の時間がかかり、画面が一瞬止まります。 (ゲーム開発チーム・クライアント開発)
- クライアントのガベージコレクション: 使い終わったメモリ（ガベージ）を回収する間、ゲーム全体が止まります。一定の間隔でカクつくのが特徴です。 (ゲーム開発チーム・クライアント開発)
- メインスレッドでの同期ロード・シェーダーコンパイル: 初めて見るエリア・モンスター・エフェクトを描画する直前に、ファイルの読み込みやシェーダーの生成を待って止まります。 (ゲーム開発チーム・クライアント開発)
- ストレージが遅くアセットストリーミングが間に合わない: HDDのような遅いストレージでは、オープンワールドのテクスチャ・モデルを読み込む速度が移動に追いつかず、オブジェクトの表示が遅れたり、ゲームが読み込みを待ってカクついたりします。 (ゲーム開発チーム・クライアント開発)
- ゲームのセキュリティモジュール（アンチチート）の検査: チートを防ぐためにゲームと一緒に動くセキュリティモジュールが、定期的に検査を行います。検査が重かったり、セキュリティサーバーとやり取りするハートビート（定期的な生存確認の信号）が遅れたりすると、カクついたり切断されたりします。 (ゲーム開発チーム・クライアント開発)
L2 クライアントのOS・端末
- Wi-Fi ↔ LTE・5Gの切り替え: 家の外に出てWi-Fiが切れ、LTE・5Gに切り替わると、自分のIPアドレスが変わり、それまでの接続が無効になります。 (ゲーム開発チーム・サーバー開発)
- クライアントのメモリ不足・スワップ: ブラウザのタブを数十個開いたままゲームを動かすと、OSがゲームのメモリの一部をディスクに追い出します。 (外部・外部)
- ビデオメモリ（VRAM）不足: グラフィックオプションが必要とするメモリがグラフィックボードのメモリより大きいと、OSがテクスチャをPCのメモリへ追い出してはまた戻すため、カクつきます。 (ゲーム開発チーム・クライアント開発)
- NICの省電力・ドライバーの問題: 有線LANアダプター・Wi-Fiチップがパケットの合間に省電力状態に入ると、再び動き出すまでに時間がかかります。 (外部・外部)
- オーバーレイソフトの干渉: メッセンジャー・ランチャー・録画・FPS表示のソフトが、ゲーム画面の上に自分のUIを重ねて描くため、ゲームのレンダリング処理に割り込みます（フック）。フレームごとの処理が増え、ときどきゲームとぶつかって一瞬止まったり、ゲームが強制終了したりします。 (外部・外部)
L3 家庭内ネットワーク
L4 インターネット回線
- BGPの経路変更・収束: インターネットの経路情報が変わり、再び収束するまでの数秒〜数十秒（まれに数分）の間、パケットが失われます。 (インフラチーム・ネットワークインフラ)
- 回線品質の不良: 端子の接触不良や古いケーブル、モデムの異常は、継続的なパケットロスと周期的な回線断を引き起こします。 (外部・外部)
L5 データセンターのネットワーク機器
- ネットワーク機器のフェイルオーバー: ルーター・ファイアウォールの1台が故障して予備機に切り替わる（フェイルオーバー）数秒の間、全員が止まります。 (インフラチーム・ネットワークインフラ)
- MTUの不一致（大きなパケットだけ消える）: 途中の区間のMTU（一度に送れるサイズ）が小さくなっているのにサイズ超過の通知がブロックされると、大きなパケットだけが消え続けます。 (インフラチーム・ネットワークインフラ)
L6 サーバーのネットワークカード
- クラウドホストのメンテナンス・ライブマイグレーション: クラウド事業者は物理サーバー（ホスト）をメンテナンスするとき、仮想マシンを別のホストに移したり（ライブマイグレーション）、一時的に止めたりします。その間はサーバー全体が止まり、止まる時間が長いと接続が切れます。 (インフラチーム・サーバーインフラ)
- NICドライバー・ファームウェアの問題: ドライバーのバグや機能の誤動作でカードが止まり、再起動している間はすべての送受信が途切れます。 (インフラチーム・サーバーインフラ)
L7 サーバーOS（カーネル）
- CPUスチール（仮想マシン）: 物理サーバー（ハイパーバイザー）が仮想マシンのCPU時間を一時的にほかの仮想マシンに回している間（CPUスチール）、ゲームサーバーが止まります。 (インフラチーム・サーバーインフラ)
- メモリの回収・コンパクションによる停止: OSがヒュージページ（huge page）を作るためにメモリをコンパクションしたり、空きメモリを回収したりしている間、プロセスが止まります。 (インフラチーム・サーバーインフラ)
L8 ソケットとプロトコル
- TCPのHOLブロッキング: TCPは順序を守るため、失われたパケットを1つ受け取り直すまで、後から届いたパケットをゲームに渡しません。 (ゲーム開発チーム・サーバー開発)
- TCPのRTOと指数バックオフ: 再送がまた失敗するたびに待ち時間が2倍に延びるため、短い回線断が長い停止になります。 (ゲーム開発チーム・サーバー開発)
- 遅いクライアントによるブロッキング送信: 回線の遅い1人の送信バッファが満杯なのに、ブロッキング方式（バッファに空きができるまで呼び出しが戻らない送信）で送ると、サーバーのスレッドがその1人を待ちます。 (ゲーム開発チーム・サーバー開発)
- SO_REUSEPORTの振り分けの偏り: 同じポートを複数のプロセスで分担して受け付けると、カーネルは接続ごとにアドレスのハッシュで担当プロセスを決め、その後は変更しません。担当プロセスが1つ止まると、そこに割り当てられた人だけが待たされます。 (ゲーム開発チーム・サーバー開発)
- WindowsのUDPソケットのWSAECONNRESETエラー: Windowsサーバーがすでに去ったクライアントにUDPを送ると、「ポート到達不能」（ICMP）の通知が返ってきます。その通知のせいで次の受信呼び出しがエラーで終わりますが、サーバーのコードがこのエラーをソケット自体の故障として扱うと、そのソケットを使っている全員が影響を受けます。 (ゲーム開発チーム・サーバー開発)
L9 サーバーのゲームプロセス
- ロック競合: 複数のスレッドが同じデータを使うために1つのロックを待つと、スレッドを増やしても一度に1つずつしか実行されません。 (ゲーム開発チーム・サーバー開発)
- デッドロック: 2つのスレッドが互いに相手の取ったロックを待つと、永遠に止まったままになります。 (ゲーム開発チーム・サーバー開発)
- ゲームスレッドの同期呼び出し: ティックの途中でDBの応答やファイルの書き込みを待つと、その時間だけサーバーのゲーム進行全体が止まります。 (ゲーム開発チーム・サーバー開発)
- タイマーの一斉発火: すべてのモンスターのリスポーン、すべてのバフの期限切れ、毎正時の報酬が同じティックに集中すると、そのティックだけ処理が数十倍重くなります。 (ゲーム開発チーム・サーバー開発)
- スレッドプールの枯渇: 処理を担うワーカースレッドがすべて遅い処理に塞がれると、新しいリクエストはいつまでも待たされます。 (ゲーム開発チーム・サーバー開発)
- 無限ループ・ロジックの暴走: バグで1ティックが終わらないとサーバーが止まり、ウォッチドッグが強制的に再起動します。 (ゲーム開発チーム・サーバー開発)
- 密集エリア進入時のスポーン集中: 人でいっぱいの街にテレポートすると、サーバーは新たに見えるようになった数百人の外見・装備・状態を一度に送らなければなりません。 (ゲーム開発チーム・サーバー開発)
L10 メモリ
- サーバーGCの全停止: Java・C#のサーバーがガベージを回収するために全スレッドを止めている間（stop-the-world）、サーバー全体が止まります。 (ゲーム開発チーム・サーバー開発)
- スクリプトエンジンのGC停止: C++のサーバーでも、クエスト・AI・スキルをLuaなどのスクリプトで動かしていると、スクリプトエンジンのGCが走っている間そのゾーンが止まります。 (ゲーム開発チーム・サーバー開発)
- アロケーションの急増: イベント中に一時オブジェクトを大量に生成すると、GCが普段よりはるかに頻繁に走ります。 (ゲーム開発チーム・サーバー開発)
- メモリリーク: 解放されないメモリが少しずつたまり、数日後にGCの多発・スワップ・強制終了につながります。 (ゲーム開発チーム・サーバー開発)
- GCスラッシング（ヒープの空き不足）: 生存データがヒープの上限に近づくと、GCが走っても回収できるものがほとんどなく、GCが休みなく繰り返されます。 (ゲーム開発チーム・サーバー開発)
- スワップ: メモリが足りずOSが一部をディスクに退避させると、そのメモリを使うたびに1,000倍以上遅いディスクを待つことになります。 (インフラチーム・サーバーインフラ)
L11 ディスク
- 同期ログ書き込み: ゲームスレッドがログを1行書くたびにディスクへの書き込み完了を待っていると、ディスクが忙しいときにゲームの進行も一緒に止まります。 (ゲーム開発チーム・サーバー開発)
- IOPS上限・キューの飽和: ディスクが1秒間に処理できる要求数を超えると、キューが長くなって遅延が急増します。 (インフラチーム・サーバーインフラ)
- サーバーの遅延ロード: サーバーがダンジョン・マップのデータを初めて要求されたときにディスクから読むと、そのティックの間、全員が止まります。 (ゲーム開発チーム・サーバー開発)
L12 データベース
- DBのフェイルオーバー: プライマリが落ちてスタンバイDBに切り替わる間は書き込みができず、レプリケーションが間に合わなかった最後のデータは失われることがあります。 (インフラチーム・DBインフラ)
- キャッシュスタンピード: 人気データのキャッシュが同時に期限切れになると、数千件の要求が一斉にDBへ殺到します。 (ゲーム開発チーム・サーバー開発)
- Redisの遅いコマンド: Redisはコマンドを1つずつ順番に処理するため、遅いコマンドが1つあると、その後ろのすべての要求が止まります。 (ゲーム開発チーム・サーバー開発)
L13 サーバー構成と運用
- ゾーン移動（サーバー間の引き継ぎ）: 別のエリアやダンジョンに入るとき、キャラクター情報を別のサーバーへ引き渡す過程で遅延や失敗が起きます。 (ゲーム開発チーム・サーバー開発)
- カスケード障害: 1つのサービスが遅くなると、それを呼び出すサーバーが応答待ちで塞がり、関係のない機能まで止まります。 (ゲーム開発チーム・サーバー開発)
- ログ・監視の過負荷: 障害が起きるとログが急増し、ログを同期で送るサーバーはログのせいでさらに遅くなります。 (ゲーム開発チーム・サーバー開発)
同期設計
- ロックステップでの最も遅いプレイヤー待ち: 全員が同じターンを一緒に計算する構造では、1人の入力が遅れると全員が待たされます。 (ゲーム開発チーム・サーバー開発)
- ホスト（部屋主）型の構成: 1人のプレイヤーのPCがサーバーの役割をすると、その人の回線とPC性能が全員の体感を決めます。 (ゲーム開発チーム・サーバー開発)
一部のユーザーだけに起きる問題
- 特定キャラクターのデータ肥大化: アイテム・郵便が数千個たまっていたり、フレンド・ブロックリストやバフが極端に多かったりするキャラクターは、接続時・保存時・周囲への通知で扱う量がほかの人の数倍になります。回線に関係なく、そのキャラクターでだけ重くなります。 (ゲーム開発チーム・サーバー開発)
TCP再送の根本原因
- 無線区間のパケットロス: Wi-Fiとモバイル回線は、無線区間で何度か再送し、それでも届かなければパケットを破棄します。破棄されたパケットは、TCPがかなり後になってから送り直します。 (外部・外部)
- ボトルネックでのキューあふれ（輻輳によるロス）: ルーター、通信事業者どうしの接続区間、データセンターの回線のように、最も細い箇所のキューが満杯になると、新しく届くパケットを破棄します。 (インフラチーム・ネットワークインフラ)
- 送信バーストによる浅いバッファのあふれ: サーバーがティックごとに数千人分の更新を一瞬でまとめて送ると、スイッチの小さなバッファやクラウドの瞬間的な上限が1ms足らずであふれ、一部が破棄されます。 (ゲーム開発チーム・サーバー開発)
- ポリサーによる超過分の破棄: 通信事業者の料金プラン、クラウドインスタンスの上限、DDoS対策機器は、決められた速度を超えるパケットをキューに入れずにすぐ破棄することもあります。 (インフラチーム・ネットワークインフラ)
- 物理エラー（不良ケーブル・光モジュール・コネクター）: ケーブルの損傷、ほこりの付いた光コネクター、寿命を迎えた光モジュールはビットエラーを起こし、壊れたパケットは機器が黙って破棄します。 (インフラチーム・ネットワークインフラ)
- デュプレックスの不一致: 片側はオートネゴシエーション、もう片側は速度・デュプレックスを固定にしておくと、片側が半二重で動作し、負荷がかかるたびに衝突（コリジョン）でパケットを失います。 (インフラチーム・ネットワークインフラ)
- 受信サーバーのホストでのパケット破棄: パケットはサーバーまで届いたのに、NICのリングバッファ（到着したパケットを一時的に入れておくバッファ）があふれたり、カーネルで受信処理を担うコアが飽和したりして破棄されます。 (インフラチーム・サーバーインフラ)
- ファイアウォール・接続追跡による破棄: ファイアウォールやLinuxの接続追跡（conntrack、通過する接続をテーブルに記録する機能）は、テーブルが満杯になったり、接続の状態が合わないと判断したりすると、パケットを破棄します。 (インフラチーム・ネットワークインフラ)
- 中間機器の処理上限超過（ファイアウォール・IPS・DDoS対策）: ファイアウォール、侵入防止システム（IPS）、DDoS対策機器は、通過するパケットを1つずつ検査します。検査能力を超えた瞬間から、処理しきれなかったパケットを破棄します。 (インフラチーム・ネットワークインフラ)
- MTUブラックホール（大きいパケットだけ繰り返し失われる）: 途中の区間が受け取れるサイズが小さくなったのに「大きすぎる」という通知（ICMP）が遮断されると、大きなパケットは何度送り直しても消え続けます。 (インフラチーム・ネットワークインフラ)
- 接続中のNAT・ロードバランサーのマッピング期限切れ: アイドル接続のマッピング（この接続をどこに転送するかを記録したエントリ）を中間機器が消すと、次に送るパケットは転送されません。再送だけを繰り返した末に切断されるか、機器が接続拒否（RST）を返してすぐに切断されます。 (ゲーム開発チーム・クライアント開発)
- 経路変更・ECMPの不良経路: インターネットの経路が切り替わる数秒の間、または複数のECMP経路のうち不良な経路に割り当てられた接続で、パケットが消えます。 (インフラチーム・ネットワークインフラ)
- 遅延の急上昇による不要な再送: パケットは消えておらず、一時的にとても遅れて届いただけなのに、その遅延がRTOより長いと、送信側はパケットロスと判断して再送します。 (外部・外部)
- RTOの設定が環境に合っていない: RTOの最小値を下げすぎると少し遅れただけで不要な再送が起き、デフォルト値（200ms）はゲームにとっては長すぎて、1回失うたびに長く止まります。 (インフラチーム・サーバーインフラ)
- thin streamの遅い回復: ゲームのように小さなパケットをまばらに送ると、「後続のパケット3つ」がそろう前にRTOが先に来ます。大容量の転送と比べて、同じパケットロスでもはるかに長く止まります。 (ゲーム開発チーム・サーバー開発)
- 中間機器によるTCPオプションの除去: 一部のファイアウォール・高速化装置がTCPオプションを消したり書き換えたりすると、複数のパケットを失ったときに1往復に1つずつしか回復できなくなったり、ウィンドウ（一度に送れる量）が小さくなったりして遅くなります。 (インフラチーム・ネットワークインフラ)
- ゼロウィンドウ（再送のように見える停止）: 受信側のプログラムがソケットを読むのが間に合わず、バッファが満杯になると、送信側は送信を止めてゼロウィンドウプローブだけを送ります。回線の問題ではありません。 (ゲーム開発チーム・クライアント開発)
図のあるメインページの症状辞典を見る