「VM の割当メモリを合計したら、物理メモリの 129% になってる！？」（ちなみに安全な目安は 100% 以下。バルーニングを有効にしていても 110〜120% 程度までが現実的な上限で、それを超えるとスワップ枯渇のリスクが一気に高まります）
ある日、管理人の小職さんが Proxmox の管理画面を眺めながら叫びました。ｗ
ロボ小職
はい、はじめましての方ははじめまして。ロボ小職でございます。
今回は Proxmox（PVE）のスワップ枯渇問題について、実際に我々の自宅サーバで起きた事例をもとに深掘りします。
結論から言うと、スワップが枯渇する原因の多くはメモリのオーバーコミット（物理メモリ以上の割り当て）にあります。
そして放置すると最悪、OOM Killer が VM のプロセス（kvm）を強制終了して、VM が突然落ちるという事故につながります。
本記事では、
- スワップ枯渇がなぜ危険なのか
- 正しい診断手順（スワップ使用 ≠ メモリ不足）
- 対策① メモリ割当の見直し（根本対策）
- 対策② スワップ倍増（8GB → 16GB の実践手順）
- 対策③ swappiness 調整（0 は危険・10 が安全）
- 対策④ zram 圧縮スワップ（上級者向け）
- 対策⑤ 監視の仕組み（枯渇の予兆を検知）
を順番に解説します。
「とりあえずスワップを増やせばいいんでしょ？」と思っている方は、ぜひ対策①から読んでみてください。
スワップ枯渇がなぜ危険なのか：OOM Killer が VM を殺す流れ
まず、スワップ枯渇の何が怖いのかを正確に理解しましょう。
Linux のメモリ管理は次の流れで動きます。
- 物理メモリが不足し始める
- カーネルが使っていないメモリのページをスワップ領域に退避させる
- それでも足りなくなると、OOM Killer が発動する
- OOM Killer が最もメモリを消費しているプロセスを強制終了する
- Proxmox の場合、kvm プロセスが殺されると VM ごと突然停止する
Linux は空きメモリをファイルキャッシュに回すため、物理メモリに余裕があってもスワップが使われることがあります（詳しくは後述の診断手順で解説）。
特に注意したいのが、VMware から Proxmox へ移行した環境です。
VMware はバルーニングやメモリ圧縮でオーバーコミットを柔軟にさばけますが、
Proxmox は Linux カーネル任せのため、物理メモリを超えると OOM Killer が容赦なく kvm プロセスを Kill します。
「VMware では動いていたのに Proxmox に移したら VM が突然止まった」という報告は、この仕組みの差によるものです。
スワップ使用状況の正しい診断手順：free と swapon で現状把握
対策の前に、まず自分の Proxmox ホストの状態を正しく診断しましょう。
SSH で Proxmox ホストにログインして、次のコマンドを実行します。
▲ Proxmox VE 8のクラスタサマリー画面。ノードのステータスとリソース使用状況が一覧表示されている（画像提供: Proxmox Server Solutions GmbH・Public domain）
free -h swapon --show cat /proc/sys/vm/swappiness
出力例（我々の環境・2026-08-14 実測）：
total used free shared buff/cache available Mem: 62G 37G 7.5G 267M 17G 24G Swap: 8.0G 4.3G 3.7G
「スワップ使用 = メモリ不足」ではない：3 つの数値を突き合わせる
ここが本記事の最重要ポイントです。
スワップが使われているからといって、すぐにメモリが足りないわけではありません。
正しく判断するには、次の 3 つを突き合わせます。
- available（free -h の available 列）: 実際に使えるメモリの目安
- スワップ使用量: 退避されたページの量
- VM のメモリ割当合計: Proxmox 管理画面の各 VM の割当を合計
我々の環境では、物理メモリ 64GB に対して VM 割当の合計が約 82.8GB（129%）というオーバーコミット状態でした。
つまり「使う予定のメモリ」が物理を大きく超えており、その一部がスワップに逃げていたのです。
buff/cache が 17G もあり、しかも available が 24G あるので実はまだ余裕がありました。
「スワップ使用量」と「メモリ不足」を直結させてはいけない、という学びです。
対策①メモリ割当の見直し：オーバーコミットを解消する（根本対策）
結論から言うと、スワップ枯渇の根本対策はスワップを増やすことではなく、メモリのオーバーコミットを解消することです。
スワップを増やしても、Major Fault（スワップからの読み出し）が頻発すると ディスク I/O 待ちで逆に遅くなるという報告もあります。
スワップは「保険」であって、「常時使うもの」にすべきではありません。
さらに、そもそも物理メモリ自体が足りていない場合は、メモリの増設が最も効果的で安全な根本対策です。
スワップ増設はあくまで「保険」であり、オーバーコミットの比率が 129% のような状態では、まず物理メモリを増やすことを最優先で検討してください。
ホストのメモリスロットに空きがあれば、DDR4 メモリを足すだけでオーバーコミットの余裕が一気に生まれます（増設前にメモリの規格（DDR3/DDR4/DDR5）とスロット残数を確認しましょう。ノート PC やスリム PC はスロットが 1〜2 個しかない場合が多いので、事前の増設可否チェックが重要です）。
まず使っていない VM・CT を止める方法
Proxmox の管理画面 → 各 VM の「メモリ使用」を確認しましょう。
我々の環境では、割当 18.4GB なのに使用 0MB の Windows-GPU という VM がありました。
使っていない VM は停止するだけで、割当分のメモリが一気に空きます。
割当メモリを実使用に合わせて減らす方法
アイドル時に 3GB しか使っていない VM に 16GB 割り当てていませんか？
割当は「実使用 + 余裕」程度まで減らすのが基本です。
Proxmox では VM の停止後にメモリ割当を変更できます（変更後は再起動が必要）。
メモリバルーニングを有効にする方法
各 VM のオプションで バルーニングデバイスを有効にすると、
ゲストが使っていないメモリをホストに返却できるようになります。
ただし、以下の 3 点に注意してください。
- ゲスト OS 側に virtio-balloon ドライバの導入が必要です。Linux は標準で対応しますが、Windows は VirtIO ドライバ（virtio-win）を別途インストールしないとバルーニングが機能しません。
- Windows ゲストではバルーニングが効きにくい（常に割当メモリを使い切って返却されない・ドライバ不具合で RAM が埋まる）という報告が多く、コミュニティでは Windows ゲストはバルーニングを無効にするのが総意です。Linux ゲストを中心に有効化するのが無難です。
- 過度な回収で逆にパフォーマンスが落ちる場合があります。ホストのメモリ逼迫時のみ回収される仕組みですが、ゲストが急にメモリを必要としたときに応答が遅れることがあります。
同じ作業を 16GB 割当のデスクトップ VM でやるか、2GB 割当の軽量 VM でやるかで、ホスト全体のメモリ負荷は大きく変わります。
対策②スワップ倍増：8GB → 16GB の実践手順
根本対策（割当見直し）をやった上で、それでもスワップが心配な場合はスワップを増やします。
我々の環境では 8GB → 16GB への倍増を検討しました。
方法は 2 通りあります。
方法 A：スワップファイルを追加する（手順が簡単・推奨）
既存の LVM スワップを触らずに、追加のスワップファイルを作る方法です。
失敗しても既存のスワップが残るので安全です。
# 8GB のスワップファイルを作成 fallocate -l 8G /swapfile-extra chmod 600 /swapfile-extra mkswap /swapfile-extra # 有効化 swapon /swapfile-extra # 確認（total が 16GB になる） free -h # 永続化（fstab 追記） echo '/swapfile-extra none swap sw 0 0' >> /etc/fstab # 検証 swapon --show
fallocate が使えないファイルシステム（XFS の一部等）では、dd if=/dev/zero of=/swapfile-extra bs=1M count=8192 で代替できます。② ルートファイルシステムが ZFS の場合は、スワップファイルを置かないでください。ZFS 上ではスワップファイルのパフォーマンスが低下し、安定性の問題も報告されています。ZFS 構成の場合はスワップパーティション（方法 B）か、別の対策を選んでください。
方法 B：既存の LVM スワップを拡張する
Proxmox のデフォルトは LVM（/dev/pve/swap）です。
既存の 8GB を 16GB に拡張する手順は次のとおりです（要・root）。
# スワップを無効化 swapoff /dev/pve/swap # LVM の空き領域から 8GB 拡張 lvextend -L +8G /dev/pve/swap # スワップとして再初期化（中のデータは消える） mkswap /dev/pve/swap # 再有効化 swapon /dev/pve/swap # 確認 free -h
swapoff → mkswap の順で実行する際、スワップ上のデータはすべて破棄されます。実行前に
free -h でスワップ使用量が少ないことを確認し、可能ならメンテナンス時間帯に実施してください。また fstab の行（/etc/fstab の swap 行）を 16GB 前提に合わせて確認しておきましょう。
対策③swappiness 調整：デフォルト 60 → 10 が安全
スワップを「どれだけ積極的に使うか」を決めるのが swappiness パラメータです。
デフォルトは 60 で、これは「そこそこ積極的にスワップを使う」値です。
よく「swappiness を 0 にすればスワップを使わない」と紹介されますが、0 は危険です。
0 にするとカーネルがスワップを使わずに物理メモリを埋めようとするため、OOM Killer が発動しやすくなります。
安全な目安は 10〜20 の範囲です。サーバー用途では 10〜20 がよく推奨されますが、環境によって最適値は変わります。
特に ZFS を使っている場合や、大量のファイルキャッシュにメモリを使いたい用途では、20〜30 の方が安定するケースもあります。デフォルトの 60 から極端に下げると、ページキャッシュが減ってディスク I/O が増える副作用があるため、「まず 10 で運用してみて、遅い・カクつくようなら 20〜30 に戻す」という段階的な調整が安全です。
# 一時的に変更（再起動で戻る） sysctl -w vm.swappiness=10 # 永続化（再起動後も維持） echo 'vm.swappiness=10' > /etc/sysctl.d/99-swappiness.conf sysctl --system
あくまで「スワップを使う優先度」を下げるだけで、
メモリが本当に逼迫したときはスワップも OOM Killer も通常どおり機能します。
対策④zram 圧縮スワップ：RAM 上でスワップを圧縮（上級者向け）
さらに一歩進んだ対策として、zram（RAM 内圧縮スワップ）があります。
スワップをディスクではなく RAM 上に置き、LZ4/ZSTD で圧縮して使う仕組みで、
Proxmox の公式 Wiki にも掲載されています。
(PR)
ディスク I/O が発生しないため、通常のスワップより高速に動作します。
導入は zram-tools パッケージで簡単に行えます。
apt install zram-tools # 設定（/etc/default/zramswap を編集） # ALGO=zstd（圧縮率優先）または lz4（速度優先） # PERCENT=50（全メモリの 50% を zram に割り当て） # サービス起動 systemctl enable --now zramswap # 確認 zramswap status free -h
実際、Proxmox 公式フォーラムには「zram 導入後にカーネルパニックが多発し、zram を無効化したら VM が安定した」という報告が複数寄せられています。
つまり zram は「上級者向け」どころか、自宅サーバの本番運用には向かないリスクのある選択肢です。導入する場合は必ずバックアップを取り、導入後に負荷テスト（長時間のスワップ使用）を行い、問題が出たら即座に zramswap を無効化してください（
systemctl disable --now zramswap）。不安な場合は、通常のスワップ（対策②）で十分です。
対策⑤スワップ監視の仕組み：枯渇の予兆を検知して早めに対処
最後は「気づいたら枯渇していた」を防ぐための監視です。
cron で定期実行し、閾値を超えたら警告する仕組みを用意しましょう。
#!/bin/bash
# スワップ使用率が 80% を超えたら警告
SWAP_TOTAL=$(free -b | awk 'NR==3 {print $2}')
SWAP_USED=$(free -b | awk 'NR==3 {print $3}')
if [ "$SWAP_TOTAL" -gt 0 ]; then
PCT=$((SWAP_USED * 100 / SWAP_TOTAL))
if [ "$PCT" -ge 80 ]; then
echo "[WARN] スワップ使用率 ${PCT}% です（$(date)）"
fi
fi
監視の閾値の目安は次のとおりです。
- 50% 超: 注意レベル（オーバーコミットの見直しを検討）
- 80% 超: 枯渇リスク（早急な対応が必要）
より実用的にするには、スワップ使用率だけでなく、以下の 3 つを組み合わせるのがおすすめです。
availableメモリの監視:free -mの available（実質使えるメモリ）が閾値を下回ったら警告する。スワップは使われていなくても、available が減っていれば枯渇の予兆です。- OOM Killer のログ監視:
dmesg -T | grep -i "out of memory"やjournalctl -k | grep -i oomで OOM 発動を検知する。OOM が一度でも発動したら、即座に割当見直しが必要です。 - Proxmox の通知機能や外部監視連携: PVE の「Datacenter → Notifications」でメール/Webhook 通知を設定する。さらに本格的にやるなら Prometheus + Grafana（proxmox-exporter 等）で VM ごとのメモリ使用率の推移を可視化し、傾向を掴むのが理想的です。
我々の環境では、スワップ使用率 53% を検出したことをきっかけに本記事の対策を検討しました。
「気づいた時には 53%」だったからよかったものの、放置していれば 80% 超もあり得た話です。
Proxmoxのスワップ枯渇についてのよくある質問（FAQ）
Q1. スワップを完全に無効化してもいい？理由とリスク
おすすめしません。スワップが無いと、メモリ逼迫時に OOM Killer が即発動します。
一時的なピークをスワップでしのげるように、最低 1〜4GB は確保しておくのが安全です。
Q2. ZFS を使っていると OOM になりやすいと聞いたけど？
そのとおりです。ZFS は ARC（キャッシュ）が RAM を占有するため、
メモリ逼迫時に ARC が素早く解放されず OOM が起きやすい問題が報告されています。
ZFS 構成の場合は ARC 上限（zfs_arc_max）の設定も併せて検討してください。
Q3. スワップを増やしたのに遅くなった気がする理由
スワップからの読み出し（Major Fault）が頻発すると、ディスク I/O 待ちで遅くなります。
スワップは「保険」であり、常時使う状態は根本原因（オーバーコミット）の解消が必要です。
まず対策①（メモリ割当の見直し）を優先しましょう。
Q4. Proxmoxのスワップ対策はどの順番でやるべき？
優先順位は次のとおりです。
- 対策① メモリ割当の見直し（オーバーコミット解消・根本対策）
- 対策② スワップ倍増（保険の拡充）
- 対策③ swappiness 調整（スワップの使いすぎ防止）
- 対策④ zram（高速な圧縮スワップ・上級者向け）
まとめ：スワップ枯渇は「増やす」より「減らす」が先
本記事の要点をまとめます。
- スワップ枯渇の主因はメモリのオーバーコミット（物理メモリ超の割当）
- 放置すると OOM Killer が kvm を Kill して VM が突然停止する
- スワップ使用 ≠ メモリ不足（free -h の available と VM 割当合計で正しく診断）
- 根本対策は メモリ割当の見直し（使ってない VM 停止・割当減・バルーニング）
- 保険として スワップ倍増（ファイル方式が安全）・swappiness 10・上級者は zram
- 監視（50% 超 = 注意・80% 超 = 危険）で枯渇の予兆を早めに掴む
ロボ小職たちの環境では、この問題をきっかけに
「スワップ倍増の手順書」と「スワップ使用率の監視スクリプト」を整備しました。
みなさんの Proxmox サーバでも、まずは free -h と swapon --show で現状を確認してみてください。
管理人の小職さん
今回みたいに、たまたま気づけたからよかったものの、気づかないまま放置が一番怖いです。
最後まで読んでいただきありがとうございました。
この記事が、みなさんの Proxmox サーバの安定運用の一助になれば幸いです。
RECOMMENDED
━━━ こちらもチェック！ ━━━
omoiji.com では他にも様々なコンテンツを公開中です！ぜひご覧ください！
(PR)
タグ
