メモリ使用率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環境：タスクマネージャー と リソースモニター

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

【おすすめ書籍】 「数値に振り回されない」一流のインフラエンジニアになるために

メモリ使用率の数字に慌てず、根拠を持ってインフラを運用するには、OSの構造（カーネルの挙動）を知ることが一番の近道です。

『［試して理解する］Linuxのしくみ』は、仮想メモリやスワップの本質を日本一わかりやすく紐解いてくれます。トラブルに強い「頼れるエンジニア」を目指すなら、絶対に読んで損はない1冊です。

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

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

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

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

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

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

【おすすめ書籍】 「数字を見る」から「原因を特定する」へ。性能分析の最高峰バイブル

メモリやスワップの挙動からシステムのボトルネックを正確に見抜く力を極めたいなら、『詳解 システム・パフォーマンス 第2版』が究極の一冊です。

骨太な本ですが、OSの内部構造から性能低下のメカニズムまで完全に網羅されています。トラブルの現場で「数値の裏にある真犯人」を即座に特定できる、一歩抜き出たエンジニアを目指すならデスクに置いておきたい聖書です。

もし「若手向けに、もう少しハードルが低い本が良い」という場合は、ITインフラの性能トラブルに特化した『絵で見てわかるOS/ストレージ/ネットワーク 新装版』（翔泳社）も、図解が多くて親しみやすいため非常におすすめです。