今回は504エラーでサイトが頻繁に応答不能になっていたので、対策を調べた時のことです。
自分の知識が不十分のため、かなり奮闘したのですが、同様の環境の方の参考になればうれしいですね。
環境
- EC2インスタンスにApacheとWordPressをインストールして記事を投稿
- AWS EC2(Amazon Linux release 2)
- Apacheのバージョン 2.4.54
- SSH接続ツール Tera term
- Cloud Watchでメモリの計測を設定済み
月に10万PV以内の規模のサイトを想定しています。
前提知識
SSHクライアントなどでサーバーに接続できる
Linuxのコマンドがなんとなくでもわかっていると理解しやすいと思います。
コマンドについては、こちらの解説記事もご参考ください。
原因調査
504エラーは、クライアントから要求された通信に対して、サーバーの応答が何らかの原因でタイムアウトしたことによって起こります。
Webサーバーが原因なので、当然Apacheに問題があるはずですがのアクセスログやエラーログを見てみるも原因の特定には至らず。
何が問題なのかしばらくわからなかったのですが、Cloud Watchでメモリを観測してみると・・・
![](https://fukugyo-shacho.jp/wp-content/uploads/2023/09/image.png)
なんと使用率が100%近くなっていました。
これでは落ちないほうがおかしいというもの。
原因を特定するため、インスタンスにリモート接続してtopコマンドで起動中プロセスのメモリの使用率を確認してみます。
USER欄にApacheの文字が多く見受けられたため、uキーを押して”Apache
”を入力後、エンターを押下。
Apacheが使用しているプロセスに絞ります。
![](https://fukugyo-shacho.jp/wp-content/uploads/2023/09/image-1.png)
画面右端を見るとわかりますが、php-fpmが多く立ち上がっているのがわかりました。
php-fpmはその性質上、処理が完了しても割り当てられたメモリが解放されないため使用量が増えていくことがあります。
この設定を変更してあげれば調整できそう。
ということで、具体的な方法は後程紹介しますが、まずは2か所、以下の値を設定してみます。
pm = static
pm.max_children = 2
変更してからの経過がこちら。
![](https://fukugyo-shacho.jp/wp-content/uploads/2023/09/image-2.png)
1週間様子を見てみましたが、やはり増え続けていますね・・・
もう一度調べなおして他のステータスも変更する必要がありそうです。
改善策を実施してみる
前述の設定だけでは足りなかったので再度php-fpmの設定をしていきます。
Tera termでインスタンスに接続し、権限をrootに変更。
sudo su -
続いてphp-fpmの設定ファイルを開きます。
vi /etc/php-fpm.d/www.conf
ファイル内の5か所を以下の値に変更。
実際には長大なファイルですが、設定箇所のみを抜粋しています。
pm.max_children = 4
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 250
それぞれ設定については、非常に簡潔にまとめられている記事があり、以下のような意味があるようです。
pm.max_children
:同時に処理をする可能性がある子プロセス数pm.start_servers
:プロセス開始時に生成される子プロセスpm.min_spare_servers
:待ち状態の子プロセスの最小の数pm.max_spare_servers
:待ち状態の子プロセスの最大の数pm.max_requests
:同時に処理をする可能性がある子プロセス数
1度目の設定では、ABでApacheの負荷テストでCPU性能を最大まで引き出せていなかったので、pm.max_children
の値を4に変更してみました。
また、変更していないところがあったため、設定内で矛盾が起きていた箇所も合わせて変更。
私の環境ではデフォルトよりかなり小さい値を設定していますが、月間10万PV以内のサイトであればこの設定で問題なさそう。
設定が完了したらApacheとphp-fpmプロセスを再起動。
Apache
sudo systemctl restart httpd
php-fpm
sudo systemctl restart php-fpm
これでもう一度様子を見てみます。
さいごに
今回調べていて、原因の特定までにかなり時間がかかりました。
やはり専門的なサーバーエンジニアでないと難しい部分もありますね・・・
また何か進展があれば記事にします。