-1

サーバーにNginx+PHPFPMをインストールしています。30人の同時ユーザーのためにサーバーに長期間負荷をかけています。

最初のユーザーの場合は正常に動作しますが、しばらくすると、502の不正なゲートウェイエラーがスローされ始めます。

nginxphp-fpmのログとphp-fpmの遅いログの一部を配置しました。

スクリプトが長時間実行され、サーバーに負荷がかかるため、php-fpmの遅いログにログインするエントリがあります。これが502不良ゲートウェイエラーの理由だと思います。しかし、私はその問題を解決する方法を知りません。

  • このエラーを解決するためにphp-fpm.confで行う必要のある調整は何ですか？
  • php-fpmからの応答をnginxに長時間待たせるにはどうすればよいですか？
  • php-fpmの最大実行時間を増やす方法は？

添付のログは次のとおりです。

NGINXログ

2013/01/29 15:03:38[エラー]2493＃0：1046562 recv（）が失敗しました（104：ピアによって接続がリセットされました）アップストリームからの応答ヘッダーの読み取り中、クライアント：49.248.0.2、サーバー：** * * .com、リクエスト： "GET MY_SCRIPT_URI HTTP / 1.1"、アップストリーム： "fastcgi：//127.0.0.1：9000"、ホスト： " * **** .com"、リファラー： "MY_SCRIPT_URL"

2013/01/29 15:03:39[エラー]2493＃0：1046561 recv（）が失敗しました（104：ピアによって接続がリセットされました）アップストリームからの応答ヘッダーの読み取り中、クライアント：49.248.0.2、サーバー：** * .com、リクエスト： "GET MY_SCRIPT_URI HTTP / 1.1"、アップストリーム： "fastcgi：//127.0.0.1：9000"、ホスト： " * **** .com"、リファラー： "MY_SCRIPT_URL"

このタイプのエラーは多数あり、ファイル全体で繰り返されています。

PHPFPMログ

[14-Feb-2013 12:54:13] ERROR: failed to ptrace(PEEKDATA) pid 10748: Input/output error (5)
[14-Feb-2013 12:54:18] ERROR: failed to ptrace(PEEKDATA) pid 10112: Input/output error (5)
[14-Feb-2013 12:54:18] ERROR: failed to ptrace(PEEKDATA) pid 12147: Input/output error (5)
[14-Feb-2013 12:54:19] ERROR: failed to ptrace(PEEKDATA) pid 30857: Input/output error (5)
[snip: many more]

PHPFPMSLOWログ

[14-Feb-2013 12:55:13] [pool www] pid 10748 script_filename = MY_SCRIPT_PATH [0x00007f446e8e06b0] curl_exec（）MY_SCRIPT_PATH_1.php：317 [0x00007f446e8e0490] callService（）MY_SCRIPT_PATH_2：1331 [0 [0x00007fff0102b4d0] convertToPurchaseOrders（）unknown：0 [0x00007f446e8de0d8] call_user_func_array（）MY_SCRIPT_PATH_4：359[0x00007f446e8dd4d0]+++ダンプに失敗しました

[14-Feb-2013 12:55:13] [pool www] pid 10117 script_filename = MY_SCRIPT_PATH [0x00007f446e8e06b0] curl_exec（）MY_SCRIPT_PATH_1.php：317 [0x00007f446e8e0490] callService（）MY_SCRIPT_PATH_2：1331 [0 [0x00007fff0102b4d0] convert（）unknown：0 [0x00007f446e8de0d8] call_user_func_array（）MY_SCRIPT_PATH_4：359[0x00007f446e8dd4d0]+++ダンプに失敗しました

4

1 に答える 1

3

まず、30人の同時ユーザーはかなり低い負荷です-アプリケーションとハードウェアにもよりますが、私はかなり多くを期待しています。

スローログを読み取ると、アプリケーションがcurl_exec（）コマンドを呼び出しており、このコマンドが遅いようです。私が推測しているのは、30人の同時ユーザーがすべてスクリプトを要求しているということです。次に、スクリプトがどこかで別のWebアプリケーションを呼び出していますが、これは応答が非常に遅いか、完全にタイムアウトします（max_execution_timephp.iniに基づく）。NGINXとPHP-FPMの詳細はわかりませんが、起動する同時PHPインスタンスの最大数があると思います。これらのインスタンスはすべてCURLリクエストが返されるのを待って拘束されているため、NGINXはPHPのインスタンスをこれ以上起動できず、代わりに不正なゲートウェイを返します。

私が最初に見るのは、CURLリクエストを非同期で実行するか、キャッシュするか、スクリプトを高速化する別の方法を見つけることによって、スクリプトの応答時間を高速化することです。同期CURLリクエストを実行することは、基本的にパフォーマンスとスケーラビリティを意味します。サイトのパフォーマンスは、呼び出しているURLのパフォーマンスとスケーラビリティに完全に依存します。

それができない場合は、CURLのタイムアウト（php.iniのmax_execution_time）を5秒に減らしてください。これにより、一部のCURLリクエストが失敗しますが、少なくともアプリはそれを処理して、より迅速にユーザーに返すことができます。また、待機しているPHPスレッドがはるかに少ないことも意味します。

おそらく、NGINXが起動するPHPインスタンスの数を増やす方法があります。それで遊ぶことはできますが、問題をわずかに動かしているだけです。多くの待機中のスレッドを適切にサポートできるWebサーバーはありません。

于 2013-02-20T12:54:29.000 に答える