先に要点
サーバーを触っていると、swap を 1GB 追加した方がいい OOM を避けるために swap を作る といった話が出てきます。
でも、これが何をしているのかが曖昧なままだと、足せば安心なのか 遅くなるのか そもそも必要なのか が判断しにくいです。
今回は、サーバーの スワップ を メモリ不足時の退避先 として整理しつつ、何が助かるのか、何がつらいのか、どんな場面なら足してよいかまで、実務目線で整理します。
スワップとは何か
スワップは、物理メモリである RAM が足りなくなったときに、あまり使っていないメモリページをディスクへ逃がしてしのぐ仕組みです。
Red Hat のドキュメントでも、swap space は RAM がいっぱいになったときに使われるもので、物理メモリの代替ではないと説明されています。
ざっくり言うとこうです。
RAM
速いが量に限りがある
アプリが普段使うメモリです。
遅いが退避先として使える
ディスクの一部を、あふれたページの逃がし先にします。
Linux カーネルの説明でも、swappiness はスワップとファイルシステムページングの相対的な I/O コストのバランスを決める設定として説明されていて、スワップはあくまでメモリ管理の一部です。
つまり、スワップは 追加メモリそのもの ではありません。遅いけれど、落ちるよりはましな逃がし先 です。
何のためにあるのか
スワップの一番大きい役割は、メモリが足りない瞬間に即座に落ちないようにすることです。
たとえば次のような場面では、一時的にメモリ使用量が跳ねます。
こういうとき、スワップがまったくないと、メモリがあふれた瞬間に OOM が起きて、プロセスが強制終了されることがあります。
一方、少量でもスワップがあると、その瞬間だけ逃がして持ちこたえられることがあります。
この意味では、スワップは 普段から積極的に使いたいもの というより、いざというときの緩衝材 です。
スワップのメリット
メリット 1
OOM を避けやすくなる
これが一番分かりやすいメリットです。小さめの VPS やメモリ余裕の少ないサーバーでは、少量のスワップがあるだけで、突発的なメモリ不足を越えやすくなります。
メリット 2
短時間のメモリ山をしのぎやすい
常時不足している状態には効きませんが、普段は足りているのに、たまに山が来る ような構成には相性がよいです。たとえば夜間バッチや一時的な再起動直後などです。
メリット 3
小さいサーバーの保険になる
1GB や 2GB の小さな VPS では、ほんの少しの追加処理でも余裕がなくなることがあります。このとき、少量のスワップは 何もしないよりは安全 になりやすいです。
スワップのデメリット
デメリット 1
RAM よりかなり遅い
一番大きいデメリットはここです。Red Hat のドキュメントでも、swap space はハードドライブ上にあり、物理メモリよりアクセスが遅いと整理されています。つまり、スワップに逃がした時点で、メモリアクセスはかなり重くなります。SSD でも RAM よりはずっと遅いので、使えれば同じ ではありません。
デメリット 2
スワップが増えると全体が鈍くなりやすい
アプリが必要なページを RAM ではなくディスクから戻すようになると、I/O 待ちが増えてレスポンスが悪くなります。これが進むと、CPU ではなくメモリ不足とディスク待ちが原因で全体が重く見えることがあります。
デメリット 3
根本的なメモリ不足を隠してしまう
スワップがあると即落ちは避けやすいので、逆に 本当は RAM が足りていない 状態に気づくのが遅れることがあります。
落ちないけれど遅い、という状態で長く運用してしまうのはありがちな失敗です。
どんなときに足す価値があるか
スワップ追加が自然なのは、次のような場面です。
場面 1
小さい VPS で一時的なメモリ山がある
常時 90% 超えではないけれど、更新やビルドでたまにあふれる。この場合は、少量のスワップが保険として効くことがあります。
場面 2
とりあえず OOM だけ先に避けたい
アプリ改修やサーバー増強の前に、まずは即死を防ぎたい。このとき、スワップを入れるのは応急処置としてはありです。
場面 3
ストレージ追加の方が早く、メモリ増設がすぐできない
ただし、これは 本対応 ではなく 時間を稼ぐ策 と考える方が安全です。
逆に、スワップを足しても解決しにくい場面
場面 1
常にメモリが足りない
平常時からアプリが重く、毎日スワップを大量に使っているなら、根本原因は RAM 不足かアプリ側のメモリ使用です。この場合は、スワップを増やしても遅いままになりやすいです。
場面 2
レイテンシ重視のサーバー
リアルタイム性が重要な処理や、応答の揺れが困る構成では、スワップ使用がそのまま体感悪化につながることがあります。落ちにくさ と 遅延の少なさ のどちらを優先するかは切り分けて考える必要があります。
場面 3
メモリリークを放置している
アプリがメモリを食い続ける状態では、スワップは一時しのぎにしかなりません。むしろ、落ちるまでの時間が延びることで発見が遅れることもあります。
スワップファイルとスワップパーティションは何が違うか
スワップは、専用パーティションでも、スワップファイルでも使えます。
Red Hat のドキュメントでも、dedicated swap partition、swap file、両方の組み合わせが案内されています。
実務ではこう考えると分かりやすいです。
スワップパーティションとスワップファイル
スワップパーティション
- ディスク設計時に先に切っておく方式
スワップファイル
- 後から追加しやすい方式
今の VPS やクラウドでは、後から足しやすいスワップファイルの方が扱いやすいことも多いです。
ただし、どちらを選んでも RAM より遅い という本質は変わりません。
swappiness はどう考えるべきか
vm.swappiness は、スワップをどのくらい積極的に使うかのバランス設定です。
Linux カーネルのドキュメントでは、0 から 200 の範囲で、スワップ I/O とファイルシステムページングの相対コストを表すものとして説明されています。
ここで大事なのは、0 にすれば完全に swap 無効 ではないことです。カーネルドキュメントでも、0 は 一定条件まで swap を開始しない という説明になっています。
また、Red Hat のナレッジベースでも、swappiness は高すぎても低すぎても性能に影響しうるため、少しずつ調整して、普段の負荷条件で試すべきだとされています。
つまり、swappiness は 魔法の高速化つまみ ではありません。
本当に大事なのは、そもそもスワップに頼らない構成にできるかです。
じゃあ結局、入れるべきか
結論をかなり実務寄りに言うと、こうです。
スワップを入れるか
入れてよい
- 小さいサーバーで
- 一時的なメモリ山があり
- OOM だけは避けたい
過信しない方がよい
- 常時メモリ不足
- 低遅延が重要
- アプリのメモリ使用そのものが不健全
つまり、スワップは あると助かることがある けれど、入れたら安心 ではありません。
サーバースワップのよくある質問
Q. スワップサイズはどれくらいが適切？
A. 一律の正解はありません。Red Hat の RHEL 9 ドキュメントでは、RAM 2GB 未満なら RAM の2倍、2〜8GB なら RAM と同量、8〜64GB なら少なくとも4GB という目安が示されています(ハイバネーションを使わない場合)。実際に必要な量はワークロード次第なので、この記事のように保険として入れ、使用量を監視しながら調整します。クラウドの仮想マシンはスワップが最初から設定されていないイメージも多いため、起動後に swapon --show などで確認します。
Q. swappiness 値とは？
A. カーネルがどれだけ積極的にスワップを使うか の数値(0-200、従来は0-100)。既定値は60です。最適な値はワークロードで変わるため、Red Hat も少しずつ変えて普段の負荷で試すよう案内しています。一時的に変えるなら sysctl vm.swappiness=10 のように指定し、再起動後も残すには /etc/sysctl.d/ に設定を書きます。
Q. SSD でスワップは問題ない？
A. 動作はしますが、SSD でも RAM よりはるかに遅いので、SSD だから問題なし とは言えません。また、スワップの読み書きが頻繁に続くと SSD への書き込み量も増えるため、常用ではなく保険としての利用にとどめ、使用量を監視します。
Q. データベースサーバーでスワップは？
A. データベースがスワップに頼る状態は避けます。バッファやキャッシュがスワップへ追い出されると、応答が大きく悪化するためです。基本は十分な RAM を確保し、バッファプールなどのメモリ設定を RAM に収まる大きさにします。そのうえで、スワップを無くすか少量だけ残して swappiness を低めにするかは、OOM で落ちるリスクと遅延のどちらを避けたいかで決めます。
Q. zram / zswap とは？
A. メモリ上に圧縮スワップ領域を作る仕組み。ディスクスワップより速い + 多少のメモリ節約。低スペック VPS、Raspberry Pi、コンテナでよく使われます。
Q. Kubernetes でスワップは？
A. 以前はスワップを無効にすることが前提でしたが、Linux ノードのスワップ対応は 1.22 でアルファ、1.28 でベータになり、1.34 で一般提供(stable)になりました。ただし kubelet の既定の動作は NoSwap で、Pod がスワップを使えるのは LimitedSwap を設定した場合だけです。使うかどうかは、メモリの requests / limits の設計とあわせて判断します。
Q. スワップが多く使われていたら何をする？
A. RAM 増設、不要なプロセス停止、アプリのメモリリーク調査、スワップ使用率の高いプロセス特定(top)、OOM Killer の動作確認、で対応。スワップ依存 が長期化すると全体性能劣化。
まとめ
サーバーのスワップは、RAM が足りないときにディスクを退避先として使う仕組みです。
メリットは、少量でもあると OOM を避けやすく、短時間のメモリ山をしのぎやすいことです。
一方で、デメリットは明確です。
- RAM よりかなり遅い
- 頼り始めると全体が鈍くなりやすい
- 根本的なメモリ不足を隠しやすい
なので、スワップは 速くする設定 ではなく、落ちにくくするための保険 として考えるのがいちばん実態に近いです。
関連で読むなら、メモリ不足の落ち方は OOMとは？メモリ不足で処理が落ちる状態を初心者向けに解説、サーバー費や転送費の見方は 帯域コストとは？画像・動画・CDNで請求が膨らみやすい理由 や 転送量課金はどこで増える？クラウド請求書で最初に見るべき項目 もつながります。
参考情報
- Red Hat: Swap space overview
- Red Hat: Getting started with swap(RHEL 9、推奨サイズの表あり)
- Kubernetes: Swap memory management
- Kubernetes Blog: Kubernetes v1.34 release(Linux node swap support が stable に)
- Linux Kernel Docs: Documentation for /proc/sys/vm/ - swappiness
- Red Hat: What does swappiness do and how does it affect swap_tendency?