メモリ使用率80%で慌てない！歴18年のプロが教える「SWAP・ページング」の本質と現場の監視術（Linux/Windows対応）

インフラエンジニアとして18年、200台規模の仮想化基盤や多種多様なシステムを運用してきましたが、若手から最も多く受ける相談が「メモリ使用率が高いので、すぐ増設が必要ですか？」というものです。

結論から言えば、メモリ使用率（％）という数字だけを見るのは、健康診断で「体重」だけを見て健康状態を判断するようなものです。

本当に重要なのは「量（％）」ではなく、その裏で行われている「動き（ページング/SWAP）」です。この記事では、現場で「本当にサーバーが悲鳴を上げている瞬間」を見極めるための知識を伝授します。

物理メモリ、SWAP、ページファイルの正体

まず、これらが何のために存在し、どう違うのかを整理しましょう。

物理メモリ（RAM）

コンピュータが直接、高速に読み書きできる「作業机」です。ここにあるデータは一瞬で処理できますが、容量に限りがあり、電源を切ると消えてしまいます。

SWAP（Linux）と ページファイル（Windows）

物理メモリが足りなくなった時、あるいは「今はあまり使わないデータ」を一時的に避難させるための、ストレージ（HDDやSSD）上の領域です。

項目	Linux (SWAP)	Windows (ページファイル)
主な場所	専用のパーティション または /swapfile	Cドライブ直下の pagefile.sys
役割	RAMの延長・緊急避難先	仮想メモリの裏付け（バッキングストア）
特徴	swappinessで利用頻度を調整可能	物理RAMが余っていても積極的に利用される

ここで重要なのは、「SWAPやページファイルは物理メモリの代わりにはならない」ということです。ストレージはRAMに比べて圧倒的に遅いため、ここへのアクセスが頻発すると、サーバーのレスポンスは劇的に低下します。

「ページング」と「スワッピング」：混同しがちな言葉の定義

現場では「スワップが発生している」という言葉がよく使われますが、技術的には「ページング」と「スワッピング」は別物です。

スワッピング（Swapping）

実行中のプロセス丸ごと（メモリ内容すべて）をディスクに追い出すこと。初期のOSで行われていた手法ですが、現代のOSでは非効率すぎるため、重度のメモリ不足時を除いてほとんど行われません。

ページング（Paging）

メモリを「ページ」という小さな単位（通常4KB）に分割し、必要なページだけをディスクと出し入れする手法です。

現代のOSが日常的に行っているのはこちらです。Linuxで「SWAP領域」を使って行われている制御の実態も、実はこの「ページング」です。

ポイント：

若手の方は、「今起きているのは『プロセス丸ごとの退場（スワップ）』なのか、『小さな断片の出し入れ（ページング）』なのか」を意識すると、OSの挙動がより深く理解できるようになります。

Windows運用の肝：コミット済みメモリの概念

Windowsサーバーを管理する上で絶対に避けて通れないのが「コミット済み（Committed）」という概念です。

Windowsにおいて、アプリケーションが「メモリを使いたい」と要求すると、OSはその分を予約します。この予約された合計量を「コミット済み」と呼びます。

• コミット済み（Commit Charge）： 現在予約されているメモリの総量。
• コミット制限（Commit Limit）： 物理メモリ ＋ ページファイルの合計。

ここが落とし穴です。

物理メモリが16GBあり、使用率が50%（8GB）だったとしても、ページファイルが小さく「コミット制限」が10GBしかなければ、あと2GB予約が入っただけで「メモリ不足」のエラーが発生し、アプリケーションがクラッシュします。

「メモリ（物理）は空いているのに、システムがメモリ不足で落ちる」という怪奇現象の正体は、このコミット制限への到達であることが多いのです。

最新のサイジング手法　なぜ「推奨値」を明示しないのか

昔の教科書には「SWAP（ページファイル）は物理メモリの2倍」と書かれていました。しかし、今の時代、そのルールは通用しません。

なぜ一律の推奨値がないのか？

1. 仮想化・クラウドの普及： 昔と違い、今は数クリックでメモリ割当を変更できます。最初に「正解」を決め打つ必要性が低くなりました。
2. メモリの大容量化： RAMを256GB積んでいるサーバーに、512GBのページファイルを確保するのはストレージの無駄です。
3. ワークロードの多様化： 常に一定のメモリを使うDBサーバーと、突発的にメモリを食うWEBサーバーでは、必要なバッファが全く異なります。

現代的なアプローチ

• 負荷テストでの実測： 構築時に疑似負荷をかけ、実際にそのシステムがどれだけの「コミット済みメモリ」を必要とするかを計測します。
• 柔軟な変更（Dynamic Sizing）： 仮想環境の強みを活かし、最初は少なめに割り当て、モニタリング結果に基づいて増減させます。
• 継続的モニタリング： 本番リリース後も、データの増加やプログラムのアップデートでメモリ使用傾向は変わります。定期的にパフォーマンスを測定し、「今の適正値」を追い続けるのがプロの仕事です。

現場で使う「神器」と見るべきポイント

トラブル時や定期点検で、もっちが必ずチェックするツールとメトリクスを紹介します。

Linux環境：top と vmstat

Linuxで free や top を見て「freeが全然ない！」と焦る必要はありません。buff/cache はOSが必要に応じて開放してくれる「余裕分」だからです。

本当に見るべきは vmstat 1 を叩いた時の si (swap-in) と so (swap-out) です。

• ここが「継続的に」0以外の数値を示しているなら、物理メモリが限界を迎え、遅いディスクとの間で激しいページングが起きています。これがサーバーが重い本当の理由です。

Windows環境：タスクマネージャー と リソースモニター

• タスクマネージャー： 「パフォーマンス」タブの「メモリ」を開き、「コミット済み」の分母（制限値）に対して分子がどこまで迫っているかを確認します。
• リソースモニター： 「メモリ」タブの 「ハードフォールト/秒」 を見ます。これは「メモリにあると思ったデータがなくて、ディスクまで取りに行った回数」です。この値が高い時間帯は、ユーザーがストレスを感じるほどレスポンスが悪化しているはずです。

---

まとめ：インフラエンジニアとして大切なこと

メモリ不足のアラートが飛んできた時、単に「使用率が80%を超えました。増設しましょう」と報告するだけなら、AIでもできます。

エンジニアとしての価値は、その裏側で何が起きているかを分析することにあります。

• ページングは頻発していないか？
• コミット制限に余裕はあるか？
• キャッシュが有効に機能しているか？

これらを複合的に判断し、「今は様子見で大丈夫」「この処理のせいで一時的にページングが発生しているが、許容範囲内だ」といった、根拠のある判断ができるようになってください。

「空き容量」という静的な数字ではなく、メモリとディスクの間の「動き」という動的な流れを追う癖をつけること。それが、現場で信頼されるエンジニアへの第一歩です。