コンテンツにスキップ 
その方法をお見せしよう。 ワードプレス PHP-FPM 負荷がかかってもページビューが高速に保たれ、サーバーがスムーズに動作するように。そのために、私は以下のような特定のパラメーターを使用している。 pm.max_children, OPcache、ソケット、タイムアウト、そして明確で信頼できる開始値を提供する。.
中心点
- pm.max_children RAMの現実的な計算
- ダイナミック ほとんどのサイトのモードとして
- オペキャッシュ アクティベーションとディメンション
- ソケット Nginx/ApacheのTCPの代わりに
- モニタリング 微調整に使用
PHP-FPMがWordPressで重要な理由
PHP-FPMに依存しているのは、FastCGIプロセスマネージャがワーカープロセスと並行してリクエストを処理するため、待ち時間が大幅に短縮されるからです。 ワードプレス-ページの応答性が大幅に向上しました。古いハンドラーに比べて、FPMはCPUとRAMの負荷を抑えています。これは、同時リクエストが多いピーク時に特に重要で、障害を避けることができます。プラグインとテーマにはメモリが必要なので、すべての子プロセスには一定のバッファが必要です。巧みなプール設定により、アイドル時間やサーバーへの過負荷を発生させることなく、変動に対処しています。ここでのクリーンなアプローチは、レスポンスタイムを短縮し、信頼性を高め、サーバーを円滑に稼動させます。 ローディング時間 常に低い。.
ファイル、プール、賢明な構造
通常、FPM プールの設定は以下のようになります。 /etc/php/[バージョン]/fpm/pool.d/または/etc/php-fpm.d/で、間違ったファイルをいじらないようにphp -iで正確なパスをチェックします。私は各サイトに別々のプールを使用しています。なぜなら、プロセスが分離されているとトラブルシューティングが簡単になり、負荷がきれいに分離されるからです。ユーザー、ソケット・パス、プロセス・マネージャー、およびすべての制限値をwww.confまたはプロジェクト固有のpool.confで定義します。ソケットには/run/php/siteA.sockのようなユニークな名前を付け、Nginxがプールを特定的に指すようにし、それらを混在させるリスクを回避している。このように明確に分けることで、一貫した リソース-割り当てと安定した配備.
安全、権利、清潔なプールの断熱材
プールごとに賭ける ユーザー そして グループ をWebルート(www-dataなど)と一致させることで、ファイルのパーミッションが一貫性を保ち、Webサーバーがソケットを使用する権限を持つようにします。Unixソケットの場合は リストの所有者, listen.group そして listen.mode (0660)を使うことで、Nginx/Apacheが確実にアクセスできるようになる。と clear_env=いいえ 私は、セキュリティを緩和することなく、必要な環境変数（外部サービス用など）を許可している。. セキュリティ.limit_extensions を.phpに設定することで、他のファイルが誤って実行されるのを防いでいます。オプションで クロス chrootも可能だが、操作に手間がかかり、すべての環境に適しているわけではない。.
プロセスマネージャのモードを正しく選択する
ほとんどのインストールでは、私は以下のモードを使用する。 ダイナミック, これは、負荷のピークを柔軟に吸収し、アイドル時にリソースを節約するためである。スタティック・モードでは、プロセス数は変更されないため、極めて均一な高負荷に有効だが、RAMを消費する。オンデマンドは必要なときだけプロセスを開始する。これは非常に小さなインスタンスでは便利だが、コールドスタートの遅延を引き起こす。変動するトラフィックはダイナミックで、一定のピークはスタティックで、低トラフィックのセットアップはオンデマンドの方がうまくいくことが多い。というのも、データが示すのは、あるモードが以下の条件を満たしているかどうかだけだからだ。 負荷 本当に着ている。.
| モード | 用途 | メリット | ヒント |
|---|---|---|---|
| ダイナミック | トラフィックの変動 | 柔軟性があり、レスポンスが良い | 最初のうちは堅実なスタート値で十分だ。 |
| 静的 | 非常に一定の高負荷 | 予測可能なRAM使用率 | RAMは十分でなければならない |
| オンデマンド | 低ベースロード | アイドリング時の経済性 | コールドスタートを考慮する |
CPUコア、I/O、適切な並列性
CPUコアとブロック操作のバランスに注意している。WordPressのリクエストはI/O（データベース、ファイルシステム、外部API）を待つことが多いので、子プロセスの数がコア数を超えることがあります。CPUを多用するセットアップ（画像処理、レポート）の場合は1-2倍コアに近づけ、I/Oを多用するサイトの場合はRAMとタイムアウトがきれいに設定されている限り2-4倍コアで動作する。私は、CPUが100 %で永久に止まっているか（プロセスが多すぎる）、長い待ち時間にもかかわらず使用率が低いか（I/Oボトルネック、キャッシュ不足）を負荷下でテストします。.
pm.max_childrenを計算する。
私は、サーバーのRAM、PHPプロセスごとの実質消費量、データベースとウェブサーバー用のバッファから始めます。 限界値 をすぐに安定させることができます。例：4GBのRAM、MySQL/Nginx/キャッシュ用に1GBのバッファ、PHPプロセスあたり100MBのØを使用した場合、40ではなく30-35の子プロセスになります。メモリを大量に消費するプラグインをたくさん使う場合は、1プロセスあたり120-150MBを計画し、プロファイルが合うかどうかテストしてください。ピークについては、私は同時リクエストに重点を置いています。50件程度の並列アクセスで、キャッシュとOPcacheが適切に機能していれば、15-25の子プロセスで十分なことが多いです。詳細な導出はこちらをご覧ください： pm.max_children を最適化, そして、やみくもに数字を見るのではなく、そこからロジックを読み取る。.
スタート、スペア、リクエストパラメータを選択
ダイナミックの場合、私はpm.start_serversを10、pm.min_spare_serversを5、pm.max_spare_serversを20に設定することが多い。 応答時間 pm.max_requestsは300-800で、プロセスの肥大化によるメモリリークを防ぎます。リクエスト待ちが発生してキューが大きくなったら、pm.max_spare_serversを増やす。アイドル状態のプロセスが多すぎる場合は、スペアの値を下げてRAMに空きが残るようにする。各変更の後、CPU、RAM、リクエスト・キュー、エラー・ログを監視します。そうしないと、チューニングは明確な決定ではなく、推測のままになってしまいます。.
タイムアウト、バージョン、メモリ制限
私は通常、request_terminate_timeoutを60～120秒に設定し、ぶら下がったスクリプトが終了し、プールが空くようにしている。 エラー PHPのバージョンは最新のもの、つまり8.1か8.2にしています。PHPのバージョンは8.1や8.2といった最新のものにしています。memory_limitは、プラグインのランドスケープや画像処理にもよりますが、256Mか512Mが多いです。多くの高解像度を処理する場合は、予備を計算し、アップロードをテストし、ログを監視してください。最終的に重要なのは、リミット、リクエスト、OPcacheの組み合わせが異常値なしに実行され、メモリ不足エラーが発生しないかどうかです。.
OPcache：WordPressのCPUターボ
なぜなら、OPcacheはコンパイルされたPHPバイトコードをRAMに保持し、CPU時間を大幅に節約するからです。 労働者 そしてすべてのページをより速くする。本番環境では、タイムスタンプのチェックを無効にし、キャッシュに十分なメモリを割り当てて、常にキャッシュが削除されないようにしている。中規模サイトでは128-192MBで十分なことが多く、大規模なインストールでは256MB以上が有効です。OPcacheのステータス・スクリプトでヒット率を監視していますが、そうしないとキャッシュが十分な大きさかどうか不明なままです。そうしないと、キャッシュが十分な大きさかどうか不明なままになってしまうからだ。成功した値の例は、ここで見ることができる：
opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=10000
opcache.validate_timestamps=0
opcache.revalidate_freq=0
WordPressの場合、ワークロードが恩恵を受けることはほとんどないが、追加のメモリが消費されるため、通常はJITをオフにする。デプロイ後、最初のユーザーがコンパイルオーバーを経験しないように、最も重要なルートやWP-CLIコマンドでキャッシュをウォームアップする。.
Nginx/Apache: TCPの代わりにソケットとハンドラの選択
WebサーバーとFPMの間でUnixソケットを使うのは、ローカルソケットの呼び出しがTCPよりもオーバーヘッドが少なく、待ち時間を節約できるからです。 パフォーマンス にある。Nginxでは、これは次のようになります: fastcgi_pass unix:/run/php/wordpress.sock;.Proxy-FastCGIを使用するApacheでは、パーミッションが正しい限り、ソケットも動作します。また、アクティブなPHPハンドラをチェックし、古い亜種よりもFPMを選択します。より詳しく違いを理解したい場合は、この概要をクリックしてください： PHPハンドラの比較, mod_php や FPM、プロキシの亜種についての誤解を避けるためです。.
FPM プールにマッチするウェブサーバのパラメータ
Nginx/ApacheのタイムアウトをFPMの値に合わせることで、どのレイヤーも早く終了しないようにしている。. fastcgi_read_timeout 私はrequest_terminate_timeout（例えば120秒）を重視している、, fastcgi_connect_timeout 私は短くしている（1～5秒）。十分 fastcgi_buffers 大きなレスポンスに対する 502/504 を防ぎます。キープアライブとワーカーの制限を現実的に設定します。 非常に長いキープアライブ接続の多くは、PHP バックエンドが必要とする スロットをブロックしてしまいます。Apache では、Event-MPM を使用し、MaxRequestWorkers を RAM に合わせて制限し、FPM がウェブサーバがバックエンドハンドラに送る数以上の子要素を並列に提供できるようにします。.
モニタリングとFPMステータスの的確な利用
そうでなければ、チューニングは純粋な直感のままであり、実際にその通りになる。 原因 htop/top は、RAM が不足していないか、プロセスがスラッシングしていないか、 CPU コアが適切に使用されているかを一目で表示します。PHP FPM のステータスページでは、キューの長さ、アクティブなプロセス、 待機中のプロセス、そしてリクエストあたりの平均処理時間を表示します。キューや待ち時間が増加している場合は、プロセスが見つからないか キャッシュが機能していない可能性があります。並列処理に興味があるなら、ここから始めるのがよいでしょう： PHPワーカーのボトルネック, なぜなら、ワーカーの数は最終的にインスタンスあたりの同時 PHP リクエスト数を制限するからです。.
スローログ、バックログ、安定したエラー診断
外れ値を見つけるために スローログ プールとセットで リクエスト_スローログ_タイムアウト を3-5秒に設定した。これによって、どのスクリプトがハングアップしているのか、外部からの呼び出しが遅くなっているのかを確認することができる。そして catch_workers_output プロセスごとの通知/警告がプールログに記録されるため、根本原因の分析がスピードアップする。さらに、ソケットlisten.backlog 私はこれをカーネルのバックログ（somaxconn）と関連付けて、OSのせいでキューが失敗しないようにしている。ログに “サーバーがpm.max_childrenに達した”「または“プールが忙しそう”である場合、並列度が低すぎるか、実際の原因がデータベース/外部サービスにあるかのどちらかである。.
よくあるつまずきと迅速な解決策
多くの問題は似たようなパターンで繰り返されるので、私は常に典型的な症状、原因、対策を準備している。 時間 を失う。高いレスポンス・タイム、502エラー、メモリー・エラーは、通常、プロセス番号の設定が正しくないか、スペア値が正しくないか、スクリプトがオーバーフローしていることを示している。実際には、1ラウンドにつき1つの変数だけを変更し、メトリクスをチェックすることが役立ちます。OPcacheを忘れたり、最大リクエストを無限大に設定したりすると、忍び寄るメモリリークで代償を払うことになる。次の表は、最も一般的なケースをまとめたものである：
| 問題 | 原因 | ソリューション |
|---|---|---|
| 高い応答速度 | max_children が少なすぎる | pm.max_childrenの再計算と増加 |
| 502 悪いゲートウェイ | プールがフルに使用されているか、予備値が厳しすぎる | pm.max_spare_serversを増やし、ログをチェックする。 |
| 使用可能なメモリサイズを使い果たす | スクリプトがリークしているか、memory_limit が低すぎる。 | pm.max_requestsを減らし、OPcacheをチェックし、制限を増やす。 |
| コールドスタートが遅い | ピーク時のオンデマンド | ダイナミックに切り替え、スタート／スペア値を増やす |
WordPress特有の負荷ドライバーを軽減
典型的なホットスポットをチェックする： admin-ajax.php, wp-json およびハートビートルートを使用します。頻繁に使用されるAJAXまたはRESTエンドポイントは、キャッシュが有効であるにもかかわらず、これらのルートを通さなければならない場合、プールを満杯にする可能性があります。より短いタイムアウト、クリーンなオブジェクトキャッシュ、および優先順位付けは、ここで役立ちます。私は、オプションとして、/wp-admin/と/wp-login.phpのために、より少ない数の子プロセスを持つ別のプールを実行します。. wp-クーロン 訪問者のトラフィック（実際のシステムcron）から切り離すことで、長く実行されるタスクが偶然ユーザーのアクセスに重ならないようにしています。永続的なオブジェクトキャッシュ（Redis/Memcached）により、DBの負荷は大幅に軽減されます。 pm.max_children 性能を落とすことなく、より低くなることが多い。.
高トラフィックの設定キャッシュ、データベース、サーバーのチューニング
トラフィックが多いときは、FPMのチューニングと積極的なページキャッシングを組み合わせて、PHPに到達するリクエストのごく一部だけを減らすようにしている。 応答時間 は予測可能なままです。リバースプロキシキャッシュやWordPressのキャッシュプラグインは、ダイナミックヒットを劇的に減らすことができる。ウェブサーバーのGzipやBrotliは帯域幅を節約し、繰り返し使用するリソースのタイムトゥファーストバイトを短縮する。データベースを無駄のない状態に保つ：オートロードオプションに注意を払い、トランジェントを整理し、クエリモニタリングを実行する。これらのモジュールにより、ハードウェアを変更することなく、インスタンスあたりの実効容量を大幅に増やすことができます。.
背圧を制御し、過負荷を避ける
リクエストを待機させる場所は、FPM のプールではなく Web サーバーのキューに置くことにしています。そのために listen.backlog ウェブサーバのワーカーがプールに無制限に殺到しないよう、適度に制限する。大きすぎるバックログはボトルネックを隠し、待ち時間のピークを増加させます。小さすぎるバックログは502エラーにつながる。FPMのリスト・キューでピークがほとんど発生せず、応答時間が安定していれば、バランスがとれていることになります。.
デプロイ、リロード、ダウンタイムゼロ
私の好み リロード そうすることで、実行中のリクエストはきれいに完了する。FPMでは、これを プロセス制御タイムアウト, 子供たちが整然とシャットダウンする時間があるように。コードがデプロイされた後、私はやみくもにOPcacheを空にするのではなく、特別にウォームアップするか、青／緑の戦略のためにvalidate_timestamps=1で短い混合フェーズを受け入れる。重要：ウェブ・サーバーには 優雅なリロード そうでなければ、プールが正常に動作しているにもかかわらず、ショート502ウィンドウが発生する危険性がある。.
仮想化とマルチサイトのための拡張ノート
仮想ホストやコンテナホストでは、RAM サイズと CFS クォータが有効であることに注意してください。 パフォーマンス そのため、私はpm.max_childrenを計算限界まで実行することはありません。ホットなプロジェクトが他のプロジェクトの速度を落とさないように、私はマルチサイト環境をプールごとに分けている。トラフィックの変動が激しい場合は、1つの大きなマシンよりも複数の小さなインスタンスによる自動スケーリングの方が良いことが多い。共有NFSやリモートストレージはファイルアクセスを拡張し、OPcacheやローカルアップロードはその多くをバッファリングする。OPcacheとローカル・アップロードがその多くをバッファリングする。これは、個々のサイトがブレークアウトしても、プラットフォームが予測可能であり続けることを意味する。.
具体的な数値の読み取りと正しい解釈
FPMのステータスでは、主に実行中のプロセス、待機中のプロセス、合計プロセスを見ている。 プール を素早く要約することができる。恒久的に増え続けるキューは、供給不足やキャッシュヒットの欠落を知らせる。リクエストが待っているにもかかわらずCPUが止まっている場合、I/Oや外部サービスがブロックしていることが多い。プロセスが常に再起動している場合、pm.max_requestsが低すぎるか、プラグインがメモリをリークしています。私はこのようなパターンを認識し、ログで検証し、その後に関連するパラメータを調整します。.
私が目を光らせているその他の実用的な価値
私は„最大児童数“カウンタ、リクエストあたりの平均処理時間、および最大リストキューを指定します。もし„アイドル“が恒常的に非常に高い FPM ステータスでは、RAM を浪費してしまう。蓄積する „スローリクエスト“の場合、まずスローログ解析に頼り、DBクエリ、外部API、画像処理をチェックする。499/408はクライアントのクラッシュ（低速ネットワーク、モバイル）、504はバックエンドのタイムアウトが短すぎることを示している。.
一言で言えば：WordPressのPHP FPMセットアップを高速化するエッセンス
私はpm.max_childrenを控えめに計算し、ダイナミックを使用し、開始/予備の値を適切に設定し、OPcacheを十分な大きさにしている。 キャッシュ が残っている。TCPの代わりにソケットを使うことで、待ち時間を減らし、タイムアウトでハングアップをなくし、最新のPHPバージョンでパフォーマンスを向上させています。モニタリングは、キュー、メモリ、レスポンスタイムに関する真実を提供します。PHPの前にキャッシュを置き、健全なデータベースを用意し、FPMをしっかりと設定することで、サイトは高速で信頼性の高い状態を保つことができる。このアプローチを一貫して適用すれば、長期的にWordPressのPHP-FPMを最大限に活用することができます。.
