「php-fpm」の記事 - Crieit

PHP-FPM 環境で .htaccess に php_value を使用したら 500 Internal Server Error

2021-11-24T23:44:18+09:00

表題の通り、 PHP-FPM 環境で .htaccess に php_value を使用したら 500 Internal Server Error. が発生したので対処をメモしておきます。

現象

php_value memory_limit 64M
php_value post_max_size 32M
php_value upload_max_filesize 16M

.htaccess にこのようなファイルアップロード関係の設定を記述しておくと、 500 Internal Server Error. が発生しました。

なお、サーバログには次のように記録されていました。

/PATH/TO/WEBDIRECTORY/.htaccess: Invalid command 'php_value', perhaps misspelled or defined by a module not included in the server configuration, referer: https://example.com/

参考

PHP-FPM 環境で .htaccess に php_value は書ける？ - mattintosh note

KUSANAGI で MySQL が頻繁に落ちる際の対処

2019-04-14T15:12:18+09:00

環境

名前	バージョン
VPS	さくらインターネット 4GB
OS	KUSANAGI 8.4.2-2 (CentOS7 ベース)
ウェブサーバー	nginx 1.15.10
PHP	PHP 7.3.4
MySQL	MariaDB 10.1.38
アプリケーション	WordPress
その他	Mackerel

問題発生

サイトにブラウザからアクセスすると「データベース接続確立エラー」となる。

状況確認

コンソールにて。

sudo cat /var/log/messages

以下のログを発見。

Apr 14 00:31:06 hoge kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0

MySQL が落ちている。

暫定対処

コンソールにて。

sudo systemctl start mysqld

「データベース接続確立エラー」は解消される。

数時間後に問題再発

「データベース接続確立エラー」

再度状況確認

コンソールにて。

sudo cat /var/log/messages

同様のログを確認。

Apr 14 07:48:32 hoge kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0

Mackerel でのメモリ状況を確認。

メモリを食いつぶした後スワップまで喰って無事死亡している。

nginx ログの確認

詳細は割愛するが、nginx のログを確認したところ、ブルートフォースアタックでの接続数増、pubsubhubbub での接続数増、行儀の悪い bot からの接続数増など様々な痕跡があった。

なお、KUSANAGI による nginx ログは以下の場所に分散している。
（筆者はしばらくの間ログ分散に気付かず、確認に時間がかかった。）

WordPress SSL

/home/kusanagi/kusanagi_html/log/nginx/ssl_access.log

※ kusanagi_html はプロビジョニングディレクトリ

WordPress HTTP

/home/kusanagi/kusanagi_html/log/nginx/access.log

※ kusanagi_html はプロビジョニングディレクトリ

恒久対処

コンソールにて。

sudo vim /etc/php-fpm.d/www.conf
/pm.max_children = 
i

PHP-FPM の設定を変更する。

pm.max_children = 50

を以下に変更。

pm.max_children = 17

[esc] キーで編集終了。

KUSANAGI (nginx + php-fpm) 再起動

sudo kusanagi restart

対処後の確認

Mackerel でのメモリ状況

ピーク時のメモリ消費量が 3.5GB 程度と、上限の 4GB から 0.5GB 程度余裕のある状態で消費しきらずに、スワップアウトも発生しない。

結果、「データベース接続確立エラー」とならず接続状況は安定している。

解説

PHP-FPM の pm.max_children はアプリケーションの最大プロセス数。php.ini ファイルでの memory_limitは 128M に設定されているため、pm.max_children を 17 に設定した場合 PHP-FPM のみで食いつぶすメモリ量を 2GB 程度に抑えることができる。
デフォルトで 1GB 程度消費しているため、計約3GB。さらに MySQL などで 0.5GB 程度消費しているものと思われる。
詳細は top コマンド等で確認できる。