KUSANAGI 1GBプランのメモリ不足をphp-fpm設定変更で解決する方法

はじめに

ConoHa VPS（1GBプラン）でKUSANAGI + WordPressを運用していると、メモリ不足に悩まされることがあります。今回はnginxの脆弱性対応をきっかけにサーバー状態を確認したところ、メモリがひっ迫していることが判明。php-fpmの設定を見直すことで大幅な改善に成功しました。同じ環境で運用している方の参考になれば幸いです。

環境

Step 1：nginxの脆弱性対応状況を確認する

nginxにv1.29.8以降へのアップデートを推奨する脆弱性情報が公開されました。KUSANAGIではnginxを独自パッケージで管理しているため、以下のコマンドでバージョンを確認します。

nginx -v は使えないので、rpmコマンドで確認します。

rpm -q kusanagi-nginx129

実行結果：

kusanagi-nginx129-1.29.8-1.el9.x86_64

nginx 1.29.8 がインストール済みであることが確認でき、脆弱性対応は完了していました。

Step 2：メモリ状況を確認する

ついでにサーバーのメモリ状況を確認してみました。

free -h

実行結果：

利用可能なメモリがわずか73MB、さらにSwapを704MBも消費しており、かなり危険な状態でした。

Step 3：メモリを食っているプロセスを特定する

何がメモリを消費しているか調べます。

ps aux --sort=-%mem | head -20

結果を見ると、php-fpmのプロセスが14本以上起動しており、1プロセスあたり約100〜148MBのメモリを消費していました。

1GBのRAMに対して、php-fpmだけで1GB以上を要求している状態です。これではSwapが溢れるのも当然です。

Step 4：php-fpmの設定を確認する

まず設定ファイルの場所を確認します。

find /etc/opt/kusanagi -name "www.conf"

見つかったパス：/etc/opt/kusanagi/php-fpm.d/www.conf

現在の設定を確認します。

cat /etc/opt/kusanagi/php-fpm.d/www.conf | grep -E "^pm"

実行結果：

pm.max_childrenが50、start_serversが10という設定は、1GBプランには完全にオーバースペックです。

Step 5：php-fpmの設定を変更する

sedコマンドで一括変更します。

sed -i 's/pm.max_children = 50/pm.max_children = 5/' /etc/opt/kusanagi/php-fpm.d/www.conf
sed -i 's/pm.start_servers = 10/pm.start_servers = 2/' /etc/opt/kusanagi/php-fpm.d/www.conf
sed -i 's/pm.min_spare_servers = 5/pm.min_spare_servers = 1/' /etc/opt/kusanagi/php-fpm.d/www.conf
sed -i 's/pm.max_spare_servers = 15/pm.max_spare_servers = 3/' /etc/opt/kusanagi/php-fpm.d/www.conf

変更後の設定を確認します。

cat /etc/opt/kusanagi/php-fpm.d/www.conf | grep -E "^pm"

Step 6：KUSANAGIを再起動して反映する

kusanagi restart

「restart completed.」と表示されれば成功です。

結果：メモリが大幅に改善

free -h

利用可能メモリが73MBから245MBへと約3.4倍に改善、Swapの使用量も265MB減少しました。

注意点

pm.max_childrenを5に絞ったことで、6人以上が同時にページにアクセスした場合はPHPの処理待ちが発生する可能性があります。ただし、KUSANAGIはfcache（静的キャッシュ）機能を持っており、キャッシュが有効なページはPHPを経由しないため、実際の影響はほとんどありません。個人ブログや中小規模のサイトであれば、この設定で十分運用できます。

まとめ

KUSANAGIのデフォルト設定はある程度スペックのあるサーバーを想定しているため、1GBプランでそのまま使うとメモリが不足しがちです。php-fpmのプロセス数を適切に絞るだけで、今回のように劇的な改善が見込めます。1GBプランでKUSANAGIを使っている方はぜひ一度確認してみてください。

正直1Gプランだと表示速度もそれほど早くないし、というより遅い気がしてて、メンテなど考えるとConHa WINGに変えようかと悩んでました。
しばらくはこの設定で様子見です！

追記：6月13日

ConoHa VPSの1GBプランでWordPressを複数運営しているんだけど、なんかもっさりするなーと思ってfree -hを叩いてみたら、思った以上にメモリがカツカツだった。

まず現状確認

free -h

              total        used        free      shared  buff/cache   available
Mem:          762Mi       636Mi        95Mi       160Mi       313Mi       126Mi
Swap:         2.0Gi       576Mi       1.4Gi

availableが126MBしかない。しかもSwapを576MBも使ってる。

Swapってのはメモリが足りなくなったときにディスクを仮想メモリとして使う仕組みで、これが大量に使われてるってことはRAMが足りてないってこと。ディスクはRAMより遅いので、Swapを多用するとサーバーが重くなる。

何がメモリを食ってるか調べる

ps aux --sort=-%mem | head -10

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
httpd   528333  5.8 23.1 1136496 181080 ?       R    6月13   0:08 php-fpm: pool www
mysql      843  0.8 16.9 1526312 132656 ?       Ssl  5月30 163:19 /usr/sbin/mariadbd
httpd   528349  4.5 14.6 1060436 114120 ?       S    6月13   0:05 php-fpm: pool www
httpd   528417  8.5 14.3 1060436 112044 ?       S    00:00   0:03 php-fpm: pool www

php-fpmが3プロセスで合計約400MB、MariaDBが132MB食ってる。

php-fpmはWordPressを動かすのに必要なので減らすにも限界があるけど、MariaDBのバッファは設定で削減できる。

MariaDBの innodb_buffer_pool_size とは

MariaDBがデータをメモリ上にキャッシュするための領域。大きいほどDBクエリが速くなるけど、その分RAMを占有する。

デフォルトは128MBになっていて、それがそのままRAMを圧迫していた。

個人ブログ程度のアクセス数なら64MBに下げても体感差はほぼない。

設定変更手順

1. 設定ファイルを確認

ls /etc/my.cnf.d/

client.cnf  enable_encryption.preset  mysql-clients.cnf  server.cnf  spider.cnf

server.cnfが対象。

2. 現在の内容を確認

cat /etc/my.cnf.d/server.cnf

中身はほぼコメントだけだった。

3. 設定を追記

echo -e "\n[mariadb]\ninnodb_buffer_pool_size=64M" >> /etc/my.cnf.d/server.cnf

追記後の確認：

cat /etc/my.cnf.d/server.cnf

[mariadb]
innodb_buffer_pool_size=64M

ちゃんと追記されてた。

4. MariaDBを再起動

systemctl restart mariadb
systemctl status mariadb

Active: active (running)になってればOK。

結果

free -h

              total        used        free      shared  buff/cache   available
Mem:          762Mi       575Mi        84Mi       157Mi       393Mi       187Mi
Swap:         2.0Gi       291Mi       1.7Gi

Swapが576MB → 291MBに半減！

availableも126MB → 187MBと余裕が生まれた。体感的にもWordPressの管理画面の動作が軽くなった気がする。

まとめ

ConoHa VPS 1GBプランでメモリが逼迫してる人は、まずinnodb_buffer_pool_size=64Mを試してみて。設定変更自体は5分もかからないし、個人ブログ規模なら64MBで十分。

Swapの使用量が目に見えて減るので、サーバーへの負荷が下がってアクセス集中時の安定性も上がるはず。