お名前.com VPS に owasp/modsecurity-crs:nginx と WordPress の Docker イメージをインストールして WordPress を表示できる状態に整えました。
しかし、作業を進めるにつれて動作が停止することが増え、VPSの再起動を繰り返す羽目に…。原因を調べてみたところ、メモリ不足（OOM: Out Of Memory） が原因であることが判明しました。
結論から言うと、Swap（スワップ領域） を設定することで、再起動を繰り返すことなく安定して動作するようになりました！
あくまでも私は、こうやってみたということで動作やセキュリティの保証はできません。
環境
パソコン Windows11
VPS OS Ubuntu 20.04.3 LTS、 Dockerを使用
こちらの続きです。
Swapを使ってみる
Swap（スワップ）とは？
スワップの仕組みについて、私なりの理解を整理しておきます。
- メモリとプロセスの関係: プログラムを実行すると「プロセス」としてメモリに読み込まれ、CPUが処理を行います。一時的な処理は終わればメモリから消えますが、常駐して動き続けるプロセスもあります。
- OOM（Out Of Memory）の発生: プログラムを次々と起動するとメモリ領域がパンパンになります。この限界に達した状態を OOM (Out Of Memory) と呼び、それ以上処理を継続できなくなってサーバーが停止・クラッシュします。
- Swapによる解決: メモリ領域をファイル（スワップファイル）としてディスク上に用意し、疑似的にメモリを広げる仕組みです。絶えず動いているわけではないアイドル状態のプロセスをディスク領域へ一時退避させることで、メモリ不足を回避できます。
参考サイト：
Ubuntu 20.04にスワップ領域を追加する方法 | DigitalOcean
WSL2/Ubuntu/Raspberry Piでのメモリ不足を解消する (zenn.dev)
【Linux】freeコマンドの内容を図解化してわかりやすく説明します
Swapの設定手順
それでは、実際の作業手順を順番に説明します。
現在のメモリとディスク使用量の確認
まずシステムのスワップ情報を確認
free -h
実行結果：
total used free shared buff/cache
available
Mem: 964Mi 623Mi 79Mi 35Mi 261Mi
153Mi
Swap: 0B 0B 0B ←使っていない。
現在のディスク使用量をチェックして、十分なスペースがあることを確認
df -h
実行結果：
Filesystem Size Used Avail Use% Mounted on
udev 466M 0 466M 0% /dev
tmpfs 97M 1.3M 96M 2% /run
/dev/vda1 78G 7.6G 70G 10% / ←ここの欄でディスク容量確認。
tmpfs 483M 0 483M 0% /dev/shmディスク容量は、こちらhttps://help.onamae.com/answer/9437で
20G→80Gにふやしています。
実施したときの様子お名前ドットコムVPSへ移行への道4-SSL/TLS化 | イチゲ ブログ (kikuichige.com)
Swap領域（2GB）の作成と有効化
参考サイトには、「システムのRAMと同等〜2倍程度が出発点として適している。RAMのフォールバック用であれば4GBを超えるスワップは原則不要」と記載されています。
今回のVPSはRAM 1GB仕様のため、2GBのスワップ領域を確保することにしました。
以下のコマンドを順番に実行します。
# 2GBのスワップファイルを作成
sudo fallocate -l 2G /swapfile
# パーミッションの制限（所有者のみ読み書き可能に設定）
sudo chmod 600 /swapfile
# スワップ領域の初期化
sudo mkswap /swapfile
# スワップの有効化
sudo swapon /swapfile
設定後の確認
free -hでSwapが正常に割り当てられたか確認します。
free -h
実行結果：
total used free shared buff/cache available
Mem: 964Mi 624Mi 84Mi 35Mi 255Mi 151Mi
Swap: 2.0Gi 0B 2.0Gi ←2Gになった。
目次へスワップファイルの永続化（fstabへの追加）
サーバーを再起動するとスワップ設定がリセットされてしまうため、/etc/fstab ファイルに追加して永続化します。
万が一に備えて /etc/fstab のバックアップを取得してから追記します。
# fstabのバックアップを作成
sudo cp /etc/fstab /etc/fstab.bak
# fstabの末尾にスワップ設定を追加
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
Swap導入の効果確認
Swap設定後、owasp/modsecurity-crs:nginx・WordPress・Django を同時起動し、さらに VS Code のリモート接続を2つ開いた状態で検証しました。
以前であればメモリ上限を超えて即座にサーバーがフリーズしていましたが、再起動なしで非常に安定して動作しています。
メモリ使用量確認
free
実行結果：
total used free shared buff/cache available
Mem: 987920 673244 73456 34812 241220 123132
Swap: 2097148 398848 1698300 ←Swapが使われている。使ってなかったら単純計算で0.67+3.9で1G超えているので、動かなくなって再起動が必要だったろう。
この状態でディスク使用量をチェック
df -h
Filesystem Size Used Avail Use% Mounted on
udev 466M 0 466M 0% /dev
tmpfs 97M 1.4M 96M 2% /run
/dev/vda1 78G 9.6G 68G 13% / ←Swapする前は7.6Gだったので2G増えてる。
tmpfs 483M 0 483M 0% /dev/shmスワップ設定の調整
参考：Ubuntu 20.04にスワップ領域を追加する方法 | DigitalOcean
スワップの動作を決めるパラメータがあるらしいので検討。
目次へ
Swappinessプロパティの調整
Ubuntu 20.04にスワップ領域を追加する方法 | DigitalOcean
swappinessパラメーターは、システムがRAMからスワップ領域にデータをスワップする頻度を設定します。これは、パーセンテージを表す0～100の値です。値が0に近い場合、カーネルは絶対に必要な場合を除いて、データをディスクにスワップしません。スワップファイルとのやり取りは、RAMとのやり取りよりもはるかに時間がかかり、パフォーマンスが大幅に低下する可能性があるという点で、「コストがかかる」ことを忘れないでください。スワップにあまり依存しないようにシステムに指示すると、通常、システムの動作が高速になります。値が100に近い場合は、RAMの空き容量をより確保するために、より多くのデータをスワップしようとします。アプリケーションのメモリプロファイルまたはサーバーの使用目的によっては、この方が良い場合もあります。
略
デスクトップの場合、swappinessの設定を60にすることは不適切な値ではありません。サーバーの場合は、値を0に近づけると良いでしょう。
ということなのでサーバーは0に近い方がいいといっても
今回の場合、Swapなしの状態と同等の0に近づけるわけにはいかない。
処理スピードが遅くなっても停止するよりかはいいので、この辺で様子見。
安定しているなら数字を下げ、不安定なら上げてみようと思う。
現在のswappiness値を確認
cat /proc/sys/vm/swappiness
出力結果
60キャッシュプレッシャー設定の調整
「システムが他のデータ上の_inode_および_dentry_の情報をキャッシュするために選択する量を設定します。」参考：Ubuntu 20.04にスワップ領域を追加する方法 | DigitalOcean
indoleはディスク上のファイル名と場所を結びつけるデータでディスク上にあるため
アクセスに時間が、かかるのでアクセスした値はメモリに残しておくという意味だと思います。
しかし、この設定値に関しては意味がよくわかりません。
現在の値を確認。100より大きい値でもいいようですが、よく分からないのでこのまま。
cat /proc/sys/vm/vfs_cache_pressure
出力結果
100スナップショットを使ってみる
メモリ不足とは関係ないが、ある程度、めどがついたのでやってみます。
スナップショットとは？
任意時点のディスクイメージを保存しておき、後からその時点の状態へ復元できる機能。
スナップショット取得手順
- お名前.com VPS (KVM) サーバーコントロールパネルでサーバーをシャットダウン。やり方はスナップショットを取得する – レンタルサーバー ご利用ガイド (onamae-server.com)
- タイムスタンプを確認し、スナップショットが保存されたことを確認。
- コントロールパネルからサーバーを再起動。
- 再起動により停止したDockerコンテナを起動 (
docker start) し、Djangoコンテナ内でrunserverを実行。 - こちら↓に再起動後にやることが書いてあります。
ディスク使用量とロールバック検証
ディスク使用量の変化
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 78G 9.7G 68G 13% /
↓スナップショットをしても変わってない？
/dev/vda1 78G 9.7G 68G 13% /
試しにすぐにロールバックしてみたが、特に変化はなかった。所感
これまで頻繁に発生していたサーバーフリーズ＆再起動地獄ですが、Swap（スワップ領域）を導入したことで劇的に安定しました！
ただし、1GBメモリ環境であることに変わりはないため、調子に乗って多くのプロセスやコンテナを同時に動かすと動作が重くなる点には注意が必要です。
目次へ
イチゲをOFUSEで応援する(御質問でもOKです）Vプリカでのお支払いがおすすめです。
MENTAやってます（ichige）
