先に要点
サーバーを触っていると、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. ストレージ追加の方が早く、メモリ増設がすぐできない
クラウドや VPS では、メモリ増設より先にスワップファイルを追加した方が手早いことがあります。
ただし、これは 本対応 ではなく 時間を稼ぐ策 と考える方が安全です。
逆に、スワップを足しても解決しにくい場面
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. RAM の50%〜100%が一般的目安。ただし、本気で OOM 回避 するならRAM の2倍、ほぼ使わせない なら数百MB〜1GB だけ確保(ログ余裕)。AWS の EC2 デフォルトはスワップなし。
Q. swappiness 値とは？
A. カーネルがどれだけ積極的にスワップを使うか の数値(0-100)。サーバーでは10-20が推奨。デフォルトの60は積極的すぎることが多い。sysctl vm.swappiness=10 で調整。
Q. SSD でスワップは問題ない？
A. 書き換え寿命の懸念は減りましたが、依然 RAM より圧倒的に遅い(数倍〜100倍)。SSD だから問題なし は性能面では誤り。SSD 寿命は現代では実用上問題なし。
Q. データベースサーバーでスワップは？
A. 推奨しません。MySQL、PostgreSQL は スワップへ落ちた瞬間に性能崩壊。スワップ無効化 + 十分な RAM または swappiness=1 で最低限のみ。
Q. zram / zswap とは？
A. メモリ上に圧縮スワップ領域を作る仕組み。ディスクスワップより速い + 多少のメモリ節約。低スペック VPS、Raspberry Pi、コンテナでよく使われます。
Q. Kubernetes でスワップは？
A. 1.22 までは無効化必須、1.22+ で alpha 機能として有効化可能。production では基本無効化のまま、リソース制限と Pod のメモリ requests で制御します。
Q. スワップが多く使われていたら何をする？
A. RAM 増設、不要なプロセス停止、アプリのメモリリーク調査、スワップ使用率の高いプロセス特定(top)、OOM Killer の動作確認、で対応。スワップ依存 が長期化すると全体性能劣化。
まとめ
サーバーのスワップは、RAM が足りないときにディスクを退避先として使う仕組みです。
メリットは、少量でもあると OOM を避けやすく、短時間のメモリ山をしのぎやすいことです。
一方で、デメリットは明確です。
- RAM よりかなり遅い
- 頼り始めると全体が鈍くなりやすい
- 根本的なメモリ不足を隠しやすい
なので、スワップは 速くする設定 ではなく、落ちにくくするための保険 として考えるのがいちばん実態に近いです。
関連で読むなら、メモリ不足の落ち方は OOMとは？メモリ不足で処理が落ちる状態を初心者向けに解説、サーバー費や転送費の見方は 帯域コストとは？画像・動画・CDNで請求が膨らみやすい理由 や 転送量課金はどこで増える？クラウド請求書で最初に見るべき項目 もつながります。
参考情報
- Red Hat: Swap space overview
- Red Hat: Creating a swap file
- Linux Kernel Docs: Documentation for /proc/sys/vm/ - swappiness
- Red Hat: What does swappiness do and how does it affect swap_tendency?