ゲームラグ白書 › L9 サーバーのゲームプロセス

ロック競合 Lock contention

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

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

複数のスレッドが同じデータを使うために1つのロックを待つと、スレッドを増やしても一度に1つずつしか実行されません。

なぜ 取引所・ギルド倉庫のような共有データを、複数のスレッドが同時に使用 → すると ロックを取ったスレッドが終わるまで、ほかのスレッドは待機 → 画面では 特定の機能だけ遅い、ひどい場合は全体のティックが遅延

症状

入力遅延, フリーズ

要因

ストール

誰に起きるか

特定の機能だけ, サーバー全体

いつ

人が集中したとき

担当

主担当 ゲーム開発チーム・サーバー開発

ゲーム開発チームの対応

ロックを細かく分ける、ロック内で行う処理を減らす、メッセージベースの構造（データごとに担当スレッドを決め、ほかのスレッドはメッセージでリクエストだけを送る）。

数値の目安

ロック内の処理が全体の20%なら、スレッドをいくら増やしてもスループットは1スレッドのときの最大5倍、40%なら2.5倍で頭打ちになります。

グラフでは

人数・負荷に連動して上昇 · リクエストの処理時間、スレッドごとのCPU・コンテキストスイッチ

確認箇所

pidstat -w -t 1でスレッドごとの自発的コンテキストスイッチ（cswch/s。資源を待って止まった回数）を、bccのoffcputime -pでスレッドがCPUを離れてどこで待っているか（コールスタックごとの待ち時間）を確認。.NETはdotnet-countersのロック競合数（.NET 9以降はdotnet.monitor.lock_contentions、8以前はMonitor Lock Contention Count）

該当する場合

負荷が増えてもCPU使用率は低いままなのに処理時間が延び、待ち時間の大半がロックを取ろうとするコールスタックに集中し、ロック競合数も一緒に上がる

該当しない場合

CPUが飽和していれば計算量の問題（ティックバジェット超過、シングルスレッドのエリア過負荷）。待っている箇所がDB・ファイルの呼び出しなら、ゲームスレッドの同期呼び出しの側

確認手段

インフラのツールで確認（ゲームコード不要）

もっと詳しく

複数のスレッドがゲームデータを共同で書き換える構造で起きます。エリア・機能ごとに1つのスレッドが担当し、メッセージだけでやり取りする構造ではロックはほとんど要りませんが、その代わり1つのスレッドに仕事が集中する問題（シングルスレッドのエリア過負荷）に注意が必要です。ゲームスレッドが、遅い保存処理の取っているロックを待つと、そのティック全体が止まります。

実際の事例

Roblox 2021: Robloxの73時間障害：サービスディスカバリ（Consul）クラスターでの競合

出典

1. Amdahl's Law in the Multicore Era IEEE
   IEEE Computer 2008の論文（著者公開版）。並列化できない割合が1−fなら、コアをいくら増やしても高速化は1/(1−f)を超えない（アムダールの法則）
2. Request scheduling Microsoft
   Orleansのグレイン（アクター）は、リクエストを1つずつ最後まで処理するシングルスレッドの実行モデルなので状態を同時に書き換えない、互いの応答を待つとデッドロックが起こり得る
3. pidstat(1) — Linux manual page sysstat
   -wのcswch/sは資源を待って止まった自発的コンテキストスイッチの回数、-tでスレッドごとに表示
4. Demonstrations of offcputime, the Linux eBPF/bcc version IO Visor
   スレッドが止まってCPUを離れていた時間（off-CPU）をコールスタックごとに集計、-pでプロセスを指定
5. Well-known EventCounters in .NET Microsoft
   Monitor Lock Contention Count（monitor-lock-contention-count）：モニターロックを取得しようとして競合が発生した回数
6. .NET runtime metrics .NET
   .NET 9以降のdotnet.monitor.lock_contentions：プロセス開始後、モニターロックを取得しようとして競合が発生した回数

あわせて読みたい原因

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

• ティックバジェット超過
• 視界（AOI）計算の急増（N²）
• ブロードキャストの急増
• シングルスレッドのエリア過負荷（ホットスポット）
• デッドロック
• ゲームスレッドの同期呼び出し
• メッセージキューの滞留
• タイマーの一斉発火
• 経路探索の急増
• シリアライズ・圧縮のコスト
• サーバークラッシュ
• スレッドプールの枯渇
• 無限ループ・ロジックの暴走
• 1体に集中する戦闘（ワールドボス）
• 密集エリア進入時のスポーン集中
• オブジェクトの蓄積（消えずに残るアイテム・召喚物）
• アップデートによるトラフィックパターンの変化

同じ症状（入力遅延）を起こすほかの層の原因

• 大人数の描画負荷 L1 クライアントのゲームプロセス
• メインスレッドのパケット処理ボトルネック L1 クライアントのゲームプロセス
• V-Syncとレンダーキュー L1 クライアントのゲームプロセス
• 省電力モード・サーマルスロットリング L2 クライアントのOS・端末
• 同じ端末の他のアプリによる帯域幅の占有 L2 クライアントのOS・端末
• ディスプレイ・入力デバイス・フレーム生成による遅延 L2 クライアントのOS・端末
• Wi-Fiチャンネルの混雑 L3 家庭内ネットワーク
• バッファブロート（ルーターのキュー） L3 家庭内ネットワーク

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