サーバー構築

VPSのスワップ領域を後から追加・調整する方法

VPSのスワップ領域を後から追加・調整する方法
目次
  1. メモリ 958MB の VPS に 4GB のスワップ。2024年4月から動かしている
  2. なぜメモリの少ない VPS にスワップが要るのか
  3. ビルド系のコマンドが一瞬でピークを作る
  4. キャッシュに使われる領域も無視できない
  5. スワップは「使われている=悪い」ではない
  6. スワップファイルを作る手順
  7. 1. 領域を確保する
  8. 2. パーミッションを 600 にする
  9. 3. スワップとして有効化する
  10. 4. fstab に書いて永続化する
  11. swappiness の調整
  12. 現在の値を見る
  13. 下げるべきか、下げなくていいか
  14. 変える場合の書き方
  15. やってはいけないこと
  16. ディスクの空きを見ずに確保する
  17. スワップで「メモリ不足」を根本解決しようとする
  18. パーミッションを緩いまま放置する
  19. よくある質問
  20. Q1. スワップはメモリの何倍にすればいいですか?
  21. Q2. スワップが使われているのは危険な状態ですか?
  22. Q3. 再起動したらスワップが消えました
  23. Q4. swappiness は下げたほうがいいですか?
  24. Q5. fallocate と dd はどちらを使うべきですか?
  25. まとめ

※本ページには広告(アフィリエイトプログラム等)が含まれます。掲載しているコマンドの出力は 2026年8月16日時点で運用中の VPS(Debian 12・メモリ 958MB)から採取した実測値です。

メモリ 958MB の VPS に 4GB のスワップ。2024年4月から動かしている

メモリの少ない VPS では、スワップを積むかどうかが安定性を決めます。手元の VPS は物理メモリ 958MB に対して 4GB のスワップを割り当てていて、`/swapfile` のタイムスタンプは 2024年4月です。

スワップは遅いから使うなという意見もありますが、それは常時スワップし続ける状態の話です。実測では 4GB のうち使われているのは 362MB(9%)で、普段は物理メモリで足りています。スワップはピーク時に落ちないための保険として効いています。

  • メモリ 1GB 前後の VPS ではスワップが必須です。無いと composer や npm で落ちます
  • 容量の目安は物理メモリの 2〜4 倍。ディスクに余裕があるなら多めでかまいません
  • 作り方は `fallocate` → `chmod 600` → `mkswap` → `swapon` → `fstab` の順です
  • 常用させたくないなら `vm.swappiness` を下げます
  • パーミッションは 600 にしてください。緩いと `mkswap` が警告し、情報漏洩の穴になります
  • fstab への書き忘れに注意してください。再起動で消えます。いちばん多い失敗です

なぜメモリの少ない VPS にスワップが要るのか

ビルド系のコマンドが一瞬でピークを作る

Web サーバーを動かすだけなら 958MB でも足ります。問題は `composer install` や `npm run build` のような、一瞬だけ大量のメモリを要求する処理です。

この瞬間にメモリが足りないと、OOM Killer が動いてまったく関係ないプロセスが殺されます。MariaDB が落ちてサイトが 500 を返す、という形で表面化することが多いです。

キャッシュに使われる領域も無視できない

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           958Mi       552Mi       147Mi        72Mi       499Mi       406Mi
Swap:          4.0Gi       362Mi       3.6Gi

ここで見るべきは free の 147Mi ではなく available の 406Mi です。`buff/cache` の 499Mi は必要になれば解放されるので、実質的に使える量は available のほうが正確です。

スワップは「使われている=悪い」ではない

362MB が使われていますが、これは長期間アクセスされていないページが退避されている状態です。むしろ物理メモリをキャッシュに回せているので効率的です。

問題なのはスワップイン・アウトが継続的に発生しているときで、それは `vmstat 1` の `si` / `so` が常時ゼロでないことで判別できます。

スワップファイルを作る手順

1. 領域を確保する

ディスクの空きを確認してから作ります。

$ df -h /
/dev/vda2        99G   46G   49G  49% /

$ sudo fallocate -l 4G /swapfile

`fallocate` が使えないファイルシステム(古い XFS など)では `dd` にします。時間はかかりますが確実です。

$ sudo dd if=/dev/zero of=/swapfile bs=1M count=4096 status=progress

2. パーミッションを 600 にする

ここを飛ばすと `mkswap` が警告を出します。スワップにはメモリの中身がそのまま書かれるので、他のユーザーから読める状態は避けます。

$ sudo chmod 600 /swapfile
$ ls -lh /swapfile
-rw------- 1 root root 4.0G Apr 12  2024 /swapfile

3. スワップとして有効化する

$ sudo mkswap /swapfile
$ sudo swapon /swapfile
$ swapon --show
NAME      TYPE SIZE USED PRIO
/swapfile file   4G 362M   -2

`TYPE` が file になっていれば成功です。パーティション方式なら `partition` と出ます。

4. fstab に書いて永続化する

ここを忘れると再起動で消えます。いちばん多い失敗がこれです。

$ echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
$ grep -i swap /etc/fstab
/swapfile none swap sw 0 0

書いたら sudo swapoff /swapfile && sudo swapon -a で、fstab の記述だけで有効化できることを確かめておくと安全です。

swappiness の調整

現在の値を見る

$ cat /proc/sys/vm/swappiness
60
$ cat /proc/sys/vm/vfs_cache_pressure
100

Debian の既定は 60 です。数字が大きいほど積極的にスワップへ追い出します。

下げるべきか、下げなくていいか

値 挙動 向く場面
60(既定) バランス型 メモリが少ない VPS はこのままでよい
10 物理メモリを優先して使う メモリに余裕があり応答速度を優先したい
1 ほぼスワップしない DB 専用機など
0 OOM 直前まで使わない 小メモリ環境では危険

メモリ 958MB の環境で swappiness を下げるのは逆効果になりがちです。物理メモリにしがみついた結果、ピーク時に OOM Killer が動くからです。手元の VPS では既定の 60 のまま運用していて、それで問題は出ていません。

変える場合の書き方

$ echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-swappiness.conf
$ sudo sysctl --system
$ cat /proc/sys/vm/swappiness

設定ファイルを置いただけで満足せず、必ず実行時の値を読み直してください。sysctl の項目によっては、対象のカーネルモジュールが読み込まれる前に適用が走って黙って失敗することがあります。

やってはいけないこと

ディスクの空きを見ずに確保する

4GB のスワップはディスクを 4GB 消費します。手元の環境は 99GB 中 46GB 使用(49%)なので余裕がありますが、残り数 GB の状態で確保するとディスクフルで別の障害を起こします。

スワップで「メモリ不足」を根本解決しようとする

スワップはディスクなので、物理メモリより桁違いに遅いです。常時スワップしている状態は、単にプランが足りていないというサインです。

パーミッションを緩いまま放置する

`chmod 600` を忘れると `mkswap` が「insecure permissions」と警告します。警告が出た時点で直すのが確実です。

よくある質問

Q1. スワップはメモリの何倍にすればいいですか?

メモリ 1GB 前後の VPS なら 2〜4 倍が扱いやすいです。手元の環境は物理メモリ 958MB に対して 4GB(約 4.3 倍)を割り当てています。ディスクに余裕があるなら多めに取っても実害はありません。

Q2. スワップが使われているのは危険な状態ですか?

使われているだけなら問題ありません。手元の環境では 4GB 中 362MB(9%)が使われていますが、これは長期間参照されていないページが退避されているだけです。危険なのは `vmstat 1` の `si`/`so` が継続的にゼロでない状態です。

Q3. 再起動したらスワップが消えました

`/etc/fstab` への追記を忘れています。`/swapfile none swap sw 0 0` の 1 行が必要です。`swapon –show` で何も表示されない場合は、まず fstab を確認してください。

Q4. swappiness は下げたほうがいいですか?

メモリの少ない VPS では既定の 60 のままで構いません。下げすぎると物理メモリにしがみつき、ピーク時に OOM Killer が動きます。手元の VPS も 60 のまま運用しています。

Q5. fallocate と dd はどちらを使うべきですか?

まず `fallocate` を試し、エラーになったら `dd` に切り替えます。fallocate は一瞬で終わりますが、ファイルシステムによっては使えません。dd は 4GB で数十秒かかりますが確実です。

まとめ

メモリの少ない VPS でスワップを積むのは、速度のためではなく落ちないためです。手元の環境では 958MB のメモリに 4GB のスワップを割り当て、2024年4月から動かしています。

作る手順は `fallocate` → `chmod 600` → `mkswap` → `swapon` です。永続化には fstab の 1 行が要ります。忘れると再起動で消えます。swappiness は小メモリ環境なら既定の 60 のままでかまいません。

出力はすべて 2026年8月16日時点で運用中の VPS から採取したものです。常駐プロセスの管理はsystemd のユニットファイル、障害の切り分けはAI を使ったログの切り分け、サーバーの初期構築はさくらの VPS の初期セットアップにまとめています。