ECCUBE3は、ECCUBE2と比べて、対応速度は格段に早いし、
その恩恵ともなるのが、コアのSymfonyですが、
EFSが使えない（おそらく、ファイル数が多すぎるのが原因）
は、解決し、今回は、こちらの問題について。
エラーが出ると、502に陥り、暴走が始まる。
単純に、エラーコードを書くと、カンタンに発生出来ました。
その都度、PHP-FPMをリブート。
実運用では、暴走しているであろうCPUの高負荷状態を、
CloudWatchで監視し、リブートさせたわけですが、
最終的には、crontabでの10分ごとの禁断の自動リブート
その結果、サーバーが落ちることはなくなりましたが、
新たな問題が発生。
決済プロセスが途中で中断される
まあ、当然予測していたわけですが、、、
A.完全停止とB.決済落ちと、どっちがいい？という、狭間でしたので。
当然、機会損失の少ないBとなるわけですが、
原因は、PHP-FPMのメモリーリーク
PHP Fatal error: Allowed memory size of xxx bytes exhausted
- エラーが起きないようコードを書き換える。
- PHP-FPMの自動リブート
1. Synfony内部まで、触っていられないし、原因が取り切れるわけではないので、
2. PHP-FPMの設定も修正し、毎分ステータスチェックの自動リブートを作りました。
PHP-FPMの設定
pm.max_requestsを上げればいいだとか、
memory_limitを上げればいいだとか、
無尽蔵のメモリーを積めば、解決するかもしれませんが、
地球温暖化対策のため、最小メモリーの512Mなので、
www.conf
pm = dynamic
pm.max_children = 8
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 128
php_admin_value[memory_limit] = 32M1プロセス 32MB x 8プロセスを上限 とし、
128リクエスト毎にプロセスを、自己再生を設定。
参考 > PHPのメモリの上限やエラーについて学ぼう！メモリの考え方基本解説
この設定でも、発生するので、
参考 > Nginx + PHP-FPM で 502 Bad Gateway が時折発生する場合の対処方法
request_terminate_timeout
単一のリクエストを処理する際のタイムアウト。この時間を過ぎるとワーカープロセスが kill されます。 このオプションは、’max_execution_time’ ini オプションが何らかの理由でスクリプトの実行を止められなかった場合に使われます。 値 ‘0’ は ‘Off’ を意味します。 使用可能な単位: s(秒)(デフォルト), m(分), h(時間) あるいは d(日)、 デフォルト値: 0
PHP: 設定 – Manual より
今のところ、3日間無停止が続いていますので、
今回、「暴走時、指定時間後、killしてくれる」が、肝だったということでしょう。
WEBなら、30秒でいいんじゃないですかね？、長くても60秒？。
しかし、デフォ0っていうのが、理解不能。せめて、初期値300などしておいてほしい箇所でした。
それでも心配なので、
ステータスチェック
CloudWatchでは、ポート監視できるのは、EC2ではなく、ALBだけ。
どの機械かはわからず、再起動も負荷。
結局、CPUのクレジットの使用下限を設けて、
リブートしか出来ないため、自前で実装。
LOGFILE=/var/log/phpfpm-check-status.log
URL=http://127.0.0.1/_healthcheck4elb.php
HTTP_STATUS=`curl -LI ${URL} -o /dev/null -w '%{http_code}\n' -s`
log=`date '+%Y-%m-%d %H:%M:%S'`" PHPFPM STATUS:${HTTP_STATUS} RESTARTED"
if [ $HTTP_STATUS = "200" ]; then
exit;
else
echo ${log} | sudo tee -a ${LOGFILE}
sudo docker stop phpfpm
sudo docker start phpfpm
fiあとは、これをcrontabで毎分実行。
エラー時には、メールで通知されると、便利かも。
その他参考