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

視界（AOI）計算の急増（N²） Area-of-interest explosion

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

誰が誰を見られるかを全員同士で比較すると、人数が10倍になったとき計算は100倍になります。

なぜすべてのキャラクター同士で距離を比較しているか、グリッドに分割していても1つのセルの周辺に数百人が集中 → すると 100人なら約1万回、1,000人なら約100万回の比較 → 画面では ワールドボスや攻城戦のように人が集中した場所でティック時間が急増し、スローモーション・カクつき

症状: スローモーション, カクつき
要因: ストール
誰に起きるか: 特定の場所・チャンネル, サーバー全体
いつ: 人が集中したとき
担当: 主担当 ゲーム開発チーム・サーバー開発
ゲーム開発チームの対応: グリッド・区域に分けて近くだけを比較、遠くの対象はまれに更新、1人が見る人数に上限。
数値の目安: 距離の比較と、見える・見えないリストの更新を合わせて2人1組あたり0.1µs（1千万分の1秒）とすると、1,000人（約100万組）なら1ティックに100msかかります。20ティックのバジェット（50ms）の2倍です。
グラフでは: 人数・負荷に連動して上昇 · サーバーのティック時間、1か所に集まった人数
確認箇所: ゾーン・チャンネルごとの人数とティック時間を同じグラフに並べ、ティック内で視界計算に使った時間を個別に計測した値を確認。個別の計測値がなければ、perf top -pでゲームプロセスの関数ごとのCPU比率
該当する場合: 1か所に集まった人数が2倍になるとティック時間が4倍近くに増え、視界・距離計算の関数がCPU時間の大半を占めている
該当しない場合: ティック時間が人数に比例して増えるか、送信・シリアライズの関数の比率が大きければ、ブロードキャストの急増かシリアライズ・圧縮のコスト側
確認手段: ゲームサーバー・クライアントのログ・メトリクスが必要

出典

Comparing Interest Management Algorithms for Massively Multiplayer Games ACM
NetGames 2006の論文（著者公開版）。全ペアの距離を測る方式は人数が増えると処理しきれず、正方形のグリッドに分ければ周囲9セルだけを確認
Replication Graph in Unreal Engine Epic Games
アクターごとにすべての接続を調べる基本の方式は、人数・アクターが多いとサーバーCPUのボトルネックになる、MMORPGなどはワールドをグリッドに分けてセルごとのリストを再利用
perf-top(1) — Linux manual page perf
実行中のプロセス（-p）やスレッド（-t）のCPU使用比率を関数（シンボル）ごとにリアルタイム表示

あわせて読みたい原因

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

同じ症状（スローモーション）を起こすほかの層の原因

固定タイムステップの追いつき処理の暴走 L1 クライアントのゲームプロセス
ロードバランサーの偏り・ヘルスチェックの誤判定 L5 データセンターのネットワーク機器
スレッド過多とコンテキストスイッチ L7 サーバーOS（カーネル）
コンテナのCPUスロットリング（CFSクォータ） L7 サーバーOS（カーネル）
サーバーの電源管理（C-state・周波数制御）による遅延スパイク L7 サーバーOS（カーネル）
定期実行ジョブ L7 サーバーOS（カーネル）
OS・カーネル・ドライバー・ファームウェアのアップデート後の性能変化 L7 サーバーOS（カーネル）
遅いクライアントによるブロッキング送信 L8 ソケットとプロトコル

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