PHP 8.3 の FPM で error_log が無音になる条件を潰す
PHP 8.3.6、Alpine 3.19 のコンテナ、nginx + php-fpm の構成。FPM のワーカーが 20 前後で回っている決済系のバッチ兼 API で、ある日から 500 が返るのに nginx の error.log にも FPM の error_log にも何も出ない、という状態が半日続いた。アプリ側は set_exception_handler で握ってレスポンスだけ返して
PHP — プログラミング言語の一つ
PHP 8.3 の FPM で prefork 後に mysqli の接続が切れる現象を追った
PHP 8.3.4、Amazon Linux 2023、FPM（pm=dynamic、pm.max_children=32）、MySQL 8.0.36 の構成で、夜間バッチ後の初回リクエストだけ「MySQL server has gone away」が出る件を追いました。アクセスは日中 1 時間あたり 1.2 万リクエスト程度、バッチは 3 万行を 500 件ずつ更新します。
PHP 8.3 で Composer の autoload を classmap に切り替えたときの実測と罠
PHP 8.3、FPM 8.3.6、Debian 12 のコンテナ。依存パッケージは 180 個ほど、アプリ側のクラスが約 1,400。PSR-4 のまま `composer dump-autoload -o` で運用していたが、リクエストごとに `vendor/composer/autoload_psr4.php` の配列を引き、存在しないクラス名のたびに `file_exists` が走るのが
PHP 8.3 の FPM で max_execution_time を超えたリクエストが 504 になるまでの挙動を実測した
PHP 8.3.4、nginx 1.24 + PHP-FPM（pm=dynamic、pm.max_children=24）、DB は MySQL 8.0。120 万行の注文テーブルに対して月次集計を走らせる管理画面があり、フロントの nginx は `fastcgi_read_timeout 60s`、PHP 側は `max_execution_time=30`。ところが実行すると 30 秒で P
PHP 8.3 の CLI で xdebug.mode=profile を本番相当データに当てたら遅すぎた話
PHP 8.3.4、Ubuntu 22.04、CLI からバッチスクリプトを叩く構成。DB から 40 万行を読んで集計し、結果を CSV に落とす処理で、本番相当のデータセットだと 1 実行 11 分かかっていた。ボトルネックの当たりを付けたくて、ローカルの同じデータで Xdebug のプロファイラを有効にした。
PHP 8.3 の FPM で slowlog を有効にしたら 504 の原因が読めた
PHP 8.3.4、Amazon Linux 2023、nginx + PHP-FPM の構成。API の一部だけが数十秒で 504 になる事象を追っていた。アクセスは平常時 200req/s 程度、重いリクエストが混ざると pm.max_children を食い潰して全体が詰まる。nginx の error_log には upstream timed out しか出ず、アプリ側のログには何も残ら
PHP 8.3 で set_error_handler が deprecation を取りこぼす条件と実務での回避
PHP 8.3.4 / Ubuntu 22.04 / nginx + PHP-FPM の構成で、社内の集計バッチを動かしていたときに気づいた話です。データ量は1日あたりの処理行数が数十万、1プロセスあたりのメモリ上限は128M。PHP 8.3 に上げた直後から、ログに `Deprecated: ...` が出ているのにアプリ側のエラーハンドラが拾わず、監視に何も上がらない状態が数日続きました。
PHP 8.3 の FPM で opcache.validate_timestamps=0 にしたらデプロイが反映されない件
PHP 8.3 + nginx + php-fpm の構成で、opcache.validate_timestamps=0 を入れたままデプロイして「古いコードが動き続ける」状態を一度作った。構成は php:8.3-fpm-alpine のコンテナ、opcache.memory_consumption=256、max_accelerated_files=20000、opcache.enable_cl
PHP 8.3のFPMでpreloadを効かせつつメモリを増やさない設定
PHP 8.3.7 + php-fpm 8.3.7、Alpine 3.19 のコンテナで、opcache.preload を入れたらワーカーのRSSが起動直後に 180MB まで跳ねた件。アプリは Laravel 11 ではなく素の DI コンテナ構成で、クラスファイルは約 3,200、preload 対象は 400 弱。FPM の pm は dynamic、pm.max_children は 2
PHP 8.3のFPMでpm.max_childrenを動的に調整する手順
PHP 8.3.4、Ubuntu 22.04のFPM環境で、アクセスが急増すると502が頻発する現象に遭遇した。pm.max_childrenを静的に設定していたが、夜間バッチと日中で負荷が全く異なり、固定値では無駄が多い。そこで、負荷に応じて動的に子プロセス数を調整する方法を試した。
PHP 8.2/8.3でPDOのprepared statementが効かない条件を潰す
PHP 8.2.13 + MySQL 8.0.35（InnoDB）、PHP-FPM + nginx の構成で、1リクエストあたり30〜60件のSELECTを叩く画面がある。負荷試験でQPSを上げるとMySQL側の`Com_stmt_prepare`と`Com_stmt_execute`の比率が1:1に近づき、prepared statementがほぼ再利用されていないことが分かった。PDOの`AT
PHP 8.2のFPMでpm.max_childrenを実測から決める手順
PHP 8.2.13 + php-fpm を Amazon Linux 2023、nginx の裏で動かしている環境の話です。ピーク時に 5 分間で約 1,200 req/s、1 リクエストあたりの PHP 実行時間は p95 で 180ms 程度。前任者が設定した `pm.max_children = 200` のまま運用していて、昼のバーストで 502 が散発し、`dmesg` には oom-
PHP 8.3 の opcache で preload が静かに効かない条件を潰す
PHP 8.3.6 / Ubuntu 22.04 / nginx + php-fpm（pool は static、pm.max_children=32）の環境で、opcache.preload を設定したのに preload 済みのはずのクラスが毎リクエスト autoload される現象に当たった。opcache_get_status() の preload_statistics を見ると scr