Skip to content
VDS · 監視とパフォーマンス

メモリとスワップ：上位ティアへの移行時期

通常のメモリ使用量と不足の見分け方、小規模ティアでスワップが必要な理由、上位プランへの移行を判断する目安を説明します。

更新日 2026年8月23日

「2 GB 中 120 MB 空き」という表示は初心者を不安にさせますし、Linux ではほとんど意味がありません。システムはファイルキャッシュのために空きメモリを意図的に使うからです。空のメモリは無駄でしかありません。実際の状況は別の列に表れます。

free を正しく読む

free -h
#               total  used   free  shared  buff/cache  available
# Mem:          1.9Gi  742Mi  102Mi    18Mi       1.1Gi      1.0Gi
# Swap:         1.0Gi  126Mi  898Mi

available を見てください。これはキャッシュを追い出すことでアプリケーションが確保できるメモリ量です。この値がゼロより十分に大きければ、マシンは正常です。この意味での free は役に立ちません。

危険なサイン：

  • available が total の 10% を下回っている。
  • Swap used が増え続け、解放されない。
  • vmstat 2 で si/so がゼロ以外の値を継続的に示している。システムが絶えずディスクへページングしています。

メモリを実際に消費しているもの：

ps aux --sort=-%mem | head -10
smem -tk -s uss 2>/dev/null | tail -10

スワップは必要か

小さなスワップはどのティアでも役立ちます。長期間使われていないページを退避させる領域をシステムに与え、短いスパイクの間にプロセスが即座に落ちるのを防ぎます。ただしメモリの代わりにはなりません。ディスクは数百倍遅いからです。

2 GB のスワップファイルを作成します：

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile && swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

システムがスワップを積極的に使おうとするのを抑えます：

sysctl -w vm.swappiness=10
echo 'vm.swappiness=10' > /etc/sysctl.d/99-swap.conf

スワップファイルはティアのディスク容量を消費することに注意してください（VDS-1 では 40 GB）。また、書き込みはディスク速度の帯域を消費します。詳しくはディスク負荷をご覧ください。

リークか、メモリ不足か

パネルのメモリグラフ /hosting/vds/m/<id> を週単位で見ると、この 2 つを区別できます。

  • ノコギリ波 — 上限まで増え、サービス再起動時に下がり、また増える。これはアプリケーションのリークです。ティアを上げても問題が先送りになるだけです。
  • 最初から上限まで平坦なプラトー — ワーキングセットが単純に収まっていません。
  • 急激な落ち込み — OOM killer がプロセスを強制終了しました。メモリ不足の記事をご覧ください。

プランを変更する前に、明らかな対策を済ませておきましょう。journal の SystemMaxUse を制限し、データベースに適切な制限を設定し（MySQL はデフォルトでかなり多く要求します）、未使用のサービスを削除し（systemctl list-units --type=service --state=running）、PHP-FPM と Gunicorn のワーカー数を減らします。

いつアップグレードすべきか

クリーンアップ後も available が何週間もゼロ付近にとどまり、スワップが常に使われ、アプリケーション全体が必要な場合は、より上位のティアに移行してください。メモリは 2、4、8、16、24、32 GB の系列で増えていきます。アップグレードは上位方向のみで、残り日数分の追加支払いが発生します。ダウングレードはできません。ディスクは縮小しないからです。詳しくはプランのアップグレードの記事をご覧ください。

よくある間違い

  • スワップを完全に無効にする。 スパイク時に、システムは 1 分間耐える代わりにプロセスを強制終了します。
  • ディスクと同じサイズのスワップを作る。 マシンは落ちませんが、何時間も這うように遅くなり、即座にクラッシュするより悪いです。
  • htop の VIRT を見る。 JVM、PostgreSQL、Node の仮想サイズは非常に大きく、消費量を反映しません。RES を見てください。

メモリは障害が起きてからではなく、起きる前に確認する必要があります。しきい値アラートを設定しましょう。簡単な方法はサイトダウンタイムのアラートの記事にあります。