ゲームラグ白書 › L10 メモリ

スワップ Swapping

原因ID mem-swap · 主担当 インフラチーム・サーバーインフラ · 副担当 ゲーム開発チーム・サーバー開発

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

メモリが足りずOSが一部をディスクに退避させると、そのメモリを使うたびに1,000倍以上遅いディスクを待つことになります。

なぜ 使用メモリが物理RAMを超える → すると OSが一部をディスクに退避させ、必要なときに読み戻す → 画面では ティックが数百msに跳ね上がり、サーバーの全ユーザーがスローモーション・フリーズ

症状

スローモーション, フリーズ

要因

ストール

誰に起きるか

サーバー全体

いつ

長時間稼働するほど, 夜のピーク時間帯

担当

主担当 インフラチーム・サーバーインフラ · 副担当 ゲーム開発チーム・サーバー開発

ゲーム開発チームの対応

プロセスのメモリ使用量に上限（ヒープサイズなど）を設け、リークを点検。

インフラチームの対応

ゲームサーバーはスワップを使わない設定、メモリのアラートで対応、スワップを無効にするとメモリ不足の瞬間に強制終了（OOM）するため、ピーク使用量より余裕のあるRAMを確保。

数値の目安

RAMの読み出し約100ns、SSDからの読み戻し約100µs（1,000倍）、ネットワーク越しのクラウドディスクは約1ms（1万倍）、HDDは10ms（10万倍）。

グラフでは

徐々に上昇 · スワップ使用量、スワップイン・アウト

確認箇所

vmstat 1のsi・so列（1秒あたりにスワップから読み込んだ量・スワップへ書き出した量）、/proc/pressure/memoryのsome・full（メモリ待ちで止まった時間の割合）、ゲームサーバープロセスのpidstat -r majflt/s（ディスクから読み込む必要があったページフォルト）をティック時間と重ねて確認

該当する場合

ラグの時刻にsiが0より大きく、ゲームサーバーのmajflt/sとmemoryのfull値が一緒に上がる

該当しない場合

si・soが0で、メモリプレッシャー（PSI）も0付近ならスワップは原因ではない。スワップがないのにmajflt/sとPSIが上がるなら、メモリが尽きてコードページを読み直している状態なので、メモリの確保が先

確認手段

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

もっと詳しく

GCを使うサーバーは回収時にヒープのあちこちを読むため、ヒープの一部がスワップされただけでも1回のGCが数秒〜数十秒に延びることがあります。スワップを無効にすると、スワップで遅くなる段階を経ずに強制終了（OOM）に進むので、空きメモリを先に確保しておく必要があります。スワップがなくても、メモリが底をつきかけるとOSが実行ファイルのコードページまでメモリから追い出しては読み直すため、強制終了の前にしばらくサーバー全体がひどく遅くなることがあります。

出典

1. Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote) Google
   「Numbers Everyone Should Know」：メインメモリ参照100ns、ディスクシーク10ms（2009年時点）
2. Documentation for /proc/sys/vm/ Linux kernel
   swappiness：スワップとファイルページ回収の相対コスト、スワップはランダムI/Oなので高コスト
3. Concepts overview Linux kernel
   ディスクに元データがあるページキャッシュとスワップ可能なページを回収し、それでも足りなければOOM Killerがプロセスを強制終了
4. Solidigm™ D7-P5520 and D7-P5620 Product Brief Solidigm
   サーバー向けNVMe SSDの99.99パーセンタイル遅延（four-nines latency）130µs：SSDの1回の読み出しが100µs前後という根拠
5. Amazon EBS General Purpose SSD volumes AWS
   クラウドの標準ディスク（gp3）の遅延は1桁ms台
6. vmstat(8) — Linux manual page procps-ng
   si：1秒あたりにスワップから読み込んだメモリ、so：1秒あたりにスワップへ書き出したメモリ
7. PSI - Pressure Stall Information Linux kernel
   /proc/pressure/memoryのsome（一部のタスクが止まっていた時間の割合）とfull（すべてのタスクが同時に止まっていた時間の割合）
8. pidstat(1) — Linux manual page sysstat
   -r：majflt/s（ディスクからページを読み込む必要があったフォルトの数）

あわせて読みたい原因

同じ層：L10 メモリ

• サーバーGCの全停止
• スクリプトエンジンのGC停止
• アロケーションの急増
• メモリリーク
• GCスラッシング（ヒープの空き不足）
• キャッシュミス
• メモリの断片化
• NUMAのリモートメモリ

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

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

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