ConoHa の 1GB VPS でこのブログを運用しています。
最近、このブログの編集などで、少しレスポンスが悪いかな？と思うことがあったので調べてみました。
Mackrel で確認
このサーバーは Mackerel で監視を行っています。
メモリのグラフを見るとこの通り、メモリを使い切ってスワップが発生していました。
2/12 に下がっているのは、サーバーの再起動を行ったためです。
ConoHa の VPS は SSD なのでスワップを使用してもパフォーマンスがそれほど下がりませんが、対応が必要そうですね…
ログインして確認
top - 02:41:50 up 10 days, 10:52, 1 user, load average: 0.23, 0.28, 0.16 Tasks: 146 total, 2 running, 144 sleeping, 0 stopped, 0 zombie %Cpu(s): 13.5 us, 8.2 sy, 0.0 ni, 29.9 id, 48.1 wa, 0.0 hi, 0.0 si, 0.3 st KiB Mem : 1016104 total, 71884 free, 850264 used, 93956 buff/cache KiB Swap: 2097148 total, 864728 free, 1232420 used. 33756 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10151 nginx 20 0 515652 39488 156 S 0.0 3.9 4:02.43 php-fpm: pool www 11860 nginx 20 0 513224 38540 4884 S 22.6 3.8 3:58.29 php-fpm: pool www 11865 nginx 20 0 517312 36992 156 S 0.0 3.6 3:59.47 php-fpm: pool www 8333 nginx 20 0 503768 36232 2664 S 0.0 3.6 0:41.22 php-fpm: pool www 8336 nginx 20 0 505852 35632 120 S 0.0 3.5 0:43.09 php-fpm: pool www 11866 nginx 20 0 515904 34208 144 S 0.0 3.4 3:58.51 php-fpm: pool www 11871 nginx 20 0 515932 34172 148 S 0.0 3.4 4:03.82 php-fpm: pool www 11861 nginx 20 0 514520 34016 152 S 0.0 3.3 3:55.40 php-fpm: pool www 10184 nginx 20 0 514968 33976 144 S 0.0 3.3 3:59.71 php-fpm: pool www 11859 nginx 20 0 515620 33012 2800 R 13.3 3.2 4:01.27 php-fpm: pool www 8334 nginx 20 0 502264 32828 156 S 0.0 3.2 0:42.17 php-fpm: pool www 11870 nginx 20 0 514280 32000 128 S 0.0 3.1 3:57.46 php-fpm: pool www 1275 mysql 20 0 1592552 31976 1884 S 3.0 3.1 28:42.91 /usr/sbin/mysqld --daemonize 8341 nginx 20 0 502420 31568 76 S 0.0 3.1 0:42.92 php-fpm: pool www 21073 nginx 20 0 505612 29876 140 S 0.0 2.9 2:24.17 php-fpm: pool www 10183 nginx 20 0 510160 19540 132 S 0.0 1.9 4:03.62 php-fpm: pool www 11874 nginx 20 0 506184 15704 136 S 0.0 1.5 3:55.12 php-fpm: pool www
php-fpm のプロセスが大量にあり、メモリを消費しているようです。
# free -h
total used free shared buff/cache available
Mem: 992M 857M 65M 72K 68M 18M
Swap: 2.0G 1.3G 729M
この通り、スワップ分を含めて2GB使っているようです。
php-fpm のチューニング
php-fpm のチューニングについて調べてみました。
pm.max_requests int
各子プロセスが、再起動するまでに実行するリクエスト数。 サードパーティのライブラリにおけるメモリリークの回避策として便利です。 再起動せずにずっとリクエストを処理させる場合は ‘0’ を指定します。 PHP_FCGI_MAX_REQUESTS と同じです。デフォルト値: 0
ということで、/etc/php-fpm.d/www.conf を編集してみました。
; The number of requests each child process should execute before respawning. ; This can be useful to work around memory leaks in 3rd party libraries. For ; endless request processing specify '0'. Equivalent to PHP_FCGI_MAX_REQUESTS. ; Default Value: 0 ;pm.max_requests = 500 pm.max_requests = 50
デフォルトでは0とのことでしたが、conf ファイルに 500 とありましたので、一旦500に編集してみます。
一旦 500 にしてみましたが、再びメモリ使用量が上昇したため、50 に変更したところ、現在のところ落ち着いています。
php-fpm を再起動して反映
# systemctl restart php-fpm.service
# free -h
total used free shared buff/cache available
Mem: 992M 125M 736M 1.2M 130M 721M
Swap: 2.0G 352M 1.7G
使用メモリが大幅に減りました。
今後は 500 リクエストごとに自動で再起動がかかるはずなので、様子見ですね。
まとめ
WordPress ような PHP をメインにしたサイトを運営する際は、php-fpm のメモリには注意すべきということが分かりました。
ConoHa のスマホアプリ「ConoHa Mobile」にはモニタリングがありますが、項目はCPU、ディスク、ネットワークとなっています。
メモリの監視もあると良いなと思いました。
Mackerel で監視しているので、メモリが 90% を超えた際にアラートメールを飛ばすようにしました。
