PHP-FPM セットアップ: パフォーマンスを最大化するには pm static を使用します

この記事の未編集バージョンは最初に公開されました ヘイデンジェームス.io 彼女の許可を得てここに掲載します 作者.

スループットを向上させ、レイテンシを短縮し、CPU とメモリをより安定して使用するために PHP-FPM を構成する最適な方法を簡単に説明します。 デフォルトでは、PHP-FPM の PM (プロセス マネージャー) 行は次のとおりです。 ダイナミック、メモリが足りない場合は、インストールすることをお勧めします。 オンデマンド。 php.net ドキュメントに基づいて 2 つのコントロール オプションを比較し、私のお気に入りがそれらとどのように異なるかを見てみましょう。 静的な 大量トラフィックの場合は午後:

午後 = ダイナミック — 子プロセスの数は、次のディレクティブに基づいて動的に構成されます。 pm.max_children、pm.start_servers、pm.min_spare_servers、pm.max_spare_servers.
午後 = オンデマンド - プロセスはオンデマンドで作成されます (サービスの開始時に pm.start_servers が起動される動的作成とは対照的です)。
午後 = 静的 — 子プロセスの数は固定されており、パラメータによって示されます。 pm.max_children.

詳細については、を参照してください。 グローバル ディレクティブの完全なリスト php-fpm.conf.

PHP-FPM プロセス マネージャーと CPU 周波数コントローラーの類似点

これは主題から外れているように思えるかもしれませんが、これを PHP-FPM 構成のトピックにリンクします。 ラップトップ、仮想マシン、専用サーバーなどで、プロセッサの速度低下を少なくとも一度は経験したことのない人はいるでしょうか? CPU 周波数のスケーリングを覚えていますか? これらのオプションは次の目的で使用できます。 nix と Windows では、プロセッサーのスロットル設定を変更することで、システムのパフォーマンスと応答性を向上させることができます。 オンデマンド на パフォーマンス*。 今回は、説明を比較して類似点を見てみましょう。

ガバナー=オンデマンド — 現在の負荷に応じてプロセッサ周波数を動的にスケーリングします。 最大周波数まで急速に上昇し、非アクティブな時間が長くなると周波数を下げます。
知事=保守派= 現在の負荷に応じた動的な周波数スケーリング。 オンデマンドよりもスムーズに周波数を増減します。
ガバナー＝パフォーマンス — 周波数は常に最大です。

詳細については、を参照してください。 プロセッサ周波数レギュレータパラメータの完全なリスト.

類似点がわかりますか? を使用するのが最善であることを納得していただくために、この比較を示したかったのです。 午後静的 PHP-FPMの場合。

プロセッサーレギュレーターパラメーターの場合 パフォーマンス ほぼ完全にサーバーの CPU 制限に依存するため、パフォーマンスを安全に向上させるのに役立ちます。 もちろん、これに加えて、温度、バッテリー充電 (ラップトップの)、プロセッサーを常に 100% で実行することによるその他の副作用などの要因もあります。 パフォーマンス設定により、最速のプロセッサ パフォーマンスが保証されます。 たとえば、次のことを読んでください。 Raspberry Piのforce_turboパラメータ、RPi パネルはレギュレーターを使用します。 パフォーマンスここでは、CPU クロック速度が低いため、パフォーマンスの向上がより顕著になります。

pm static を使用してサーバーのパフォーマンスを最大化する

PHP-FPM オプション 午後静的 サーバーの空きメモリに大きく依存します。 メモリが少ない場合は選択することをお勧めします オンデマンド または ダイナミック。 一方、メモリがある場合は、pm を設定することで PHP プロセス マネージャーのオーバーヘッドを回避できます。 静的な サーバーの最大容量まで。 言い換えれば、すべてがうまく計算されていれば、次のことを確立する必要があります。 pm.static 実行可能な PHP-FPM プロセスの最大量まで、 メモリ不足やキャッシュ不足による問題を引き起こすことなく、 ただし、プロセッサーを圧倒し、実行を待機している多数の PHP-FPM 操作が蓄積されるほど高くはありません。.

上のスクリーンショットでは、サーバーには pm = 静的、および pm.max_children = 100で、これは使用可能な 10 GB のうち約 32 GB を占めます。強調表示された列に注目してください。ここではすべてが明確です。 このスクリーンショットでは、Google Analytics に約 200 人のアクティブ ユーザー (60 秒以上) が含まれています。 このレベルでは、PHP-FPM 子プロセスの約 70% がまだアイドル状態です。 これは、現在のトラフィックに関係なく、PHP-FPM が常にサーバー リソースの最大量に設定されることを意味します。 アイドル状態のプロセスはトラフィックのピークを待ち、即座に応答します。 まで待つ必要はありません pm 子プロセスを作成し、期間が経過すると子プロセスを終了します pm.process_idle_timeout。 値を非常に高く設定しました pm.max_requestsこれは、PHP でのメモリ リークのない正常に動作しているサーバーであるためです。 インストールできます pm.max_requests = 0 既存および将来の PHP スクリプトに完全な自信がある場合は、静的を使用してください。 ただし、時間をかけてスクリプトを再実行することをお勧めします。 不必要な PM コストを避けたいため、リクエストの数を多く設定します。 たとえば、少なくとも pm.max_requests = 1000 - 数量に応じて pm.max_children および XNUMX 秒あたりのリクエスト数。

スクリーンショットはコマンドを示しています Linuxトップ、u (ユーザー) と PHP-FPM ユーザー名でフィルタリングされます。 最初の 50 ほどのプロセスのみが表示されます (正確に数えたわけではありません) が、基本的に「top」にはターミナル ウィンドウに収まる上位の統計が表示されます。 この場合は、% CPU (%CPU) でソートされています。 100 個の PHP-FPM プロセスをすべて表示するには、次のコマンドを実行します。

top -bn1 | grep php-fpm

pm オンデマンドとダイナミックをいつ使用するか

午後をご利用の場合 ダイナミック、次のようなエラーが発生します。

WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total children

パラメータを変更してみてください。次のようにエラーは消えません。 Serverfault のこの投稿で説明されています。 この場合、pm.min 値が小さすぎ、Web トラフィックの変動が大きく、山も谷も深いため、pm.min を適切に調整することが困難です。 ダイナミック。 通常はpmが使用されます オンデマンド, 同じ投稿でアドバイスしたように。 しかし、これはさらに悪いことです。 オンデマンド トラフィックがほとんどない、またはまったくない場合、アイドル プロセスをゼロに終了しますが、それでもトラフィックの変更によるオーバーヘッドが発生します。 もちろん、膨大な待ち時間を設定した場合を除きます。 そして、それを使用する方が良いです pm.static + 高い数値 pm.max_requests.

PM ダイナミック 特に オンデマンド 複数の PHP-FPM プールがある場合に便利です。 たとえば、複数の cPanel アカウントまたは複数の Web サイトを異なるプールでホストするとします。 たとえば、100 個以上の cpanel アカウントと約 200 個のドメインを持つサーバーがありますが、pm.static や動的でさえも私を救うことはできません。 ここで必要なのは オンデマンド結局のところ、Web サイトの XNUMX 分の XNUMX 以上はトラフィックをほとんど、またはまったく受け取っていません。 オンデマンド すべての子プロセスが削除されるため、メモリが大幅に節約されます。 幸いなことに、cPanel 開発者はこれに気づき、値をデフォルトに設定しました。 オンデマンド。 以前は、デフォルトが ダイナミック, PHP-FPM は、負荷の高い共有サーバーにはまったく適していませんでした。 多くの人が使用しています 補足、午後だから ダイナミック アイドル状態のプールや cPanel PHP-FPM アカウントでもメモリを消費します。 おそらく、トラフィックが良好であれば、多数の PHP-FPM プールを備えたサーバー (共有ホスティング) でホストされることはありません。

まとめ

PHP-FPM を使用していてトラフィックが多い場合は、プロセス マネージャー オンデマンド и ダイナミック PHP-FPM の場合、固有のオーバーヘッドによりスループットが制限されます。 システムを理解し、サーバーの最大容量に応じて PHP-FPM プロセスを構成します。 最初のセット pm.max_children PMの最大使用量に応じて ダイナミック または オンデマンドを選択し、メモリとプロセッサが過負荷にならずに動作するレベルまでこの値を増やします。 それに気づくでしょう 午後静的、すべてがメモリ内にあるため、トラフィックの急増による CPU の急増は時間の経過とともに減少し、サーバーと CPU の負荷平均は横ばいになります。 PHP-FPM プロセスの平均サイズは Web サーバーによって異なり、手動構成が必要なため、より自動化されたプロセス マネージャーが必要になります。 ダイナミック и オンデマンド - もっと人気があります。 この記事がお役に立てば幸いです。

UPD ベンチマークチャートを追加しました ab。 PHP-FPM プロセスがメモリ内にある場合、プロセスが待機してメモリを消費する代わりにパフォーマンスが向上します。 自分にとって最適な選択肢を見つけてください。

出所： habr.com