nginx がエラー 502 を報告した場合はどうすればよいですか?この記事では、nginx エラー 502 の解決策について説明します。皆さんのお役に立てれば幸いです。
http リクエスト プロセス: 通常の状況では、動的リクエストを送信すると、nginx はリクエストを php-fpm に直接転送し、php-fpm が php-fpm を割り当てます。 cgi プロセスは関連するリクエストを処理し、順番に返し、最後に nginx は結果をクライアントのブラウザにフィードバックします。
Nginx 502 Bad Gateway エラーは FastCGI の問題です
解決策
502 の問題が発生した場合は、次のことを行うことができます。次の 2 つの手順に従って解決してください。
1. 現在の PHP FastCGI プロセスの数が十分であるかどうかを確認します (max_children 値)
netstat -anpo | grep "php-cgi"| wc -l
実際に使用されている「FastCGI プロセス」の数が、デフォルトの「FastCGI「プロセス数」」の場合、「FastCGIプロセス数」が十分ではないため、増やす必要があることを意味します。
2. 一部の PHP プログラムの実行時間が Nginx の待機時間を超えます (php のメモリ不足)
nginx.conf 設定ファイルの FastCGI タイムアウト時間を増やします例:
fastcgi_connect_timeout 300; fastcgi_send_timeout 300; fastcgi_read_timeout 300;
php.ini の :memory_limit=64M
で、nginx を再起動します。
この変更後に問題を解決できない場合は、次の解決策を参照してください:
3、max-children および max-requests
One nginx php (fpm) xcache がサーバー上で実行されており、毎日の平均アクセス数は約 300W pv
最近、この状況が頻繁に発生します。php ページが開くのが非常に遅く、CPU 使用率が突然低下します。システム負荷が非常に低いレベルに上昇すると、突然非常に高いレベルに上昇する場合、ネットワーク カードのトラフィックをチェックすると、突然非常に低いレベルに低下することがわかります。この状況は数秒間だけ続きましたが、その後回復しました。
php-fpm のログ ファイルをチェックすると、いくつかの手がかりが見つかりました:
Sep3008:32:23.289973[NOTICE] fpm_unix_init_main(), line 271: getrlimit(nofile): max:51200,cur:51200 Sep3008:32:23.290212[NOTICE] fpm_sockets_init_main(), line 371:using inherited socket fd=10,“127.0.0.1:9000″ Sep3008:32:23.290342[NOTICE] fpm_event_init_main(), line 109: libevent:using epoll Sep3008:32:23.296426[NOTICE] fpm_init(), line 47: fpm is running, pid 30587
これらの文の前に、閉じている子が 1,000 行以上あります。そして、子のログをオンにします
php-fpm にはパラメータ max_requests があり、各子が閉じられるまでに処理できるリクエストの最大数を指定することがわかりました。デフォルト設定は 500 です。 PHP は各子にリクエストをポーリングするため、トラフィックが多い場合、各子は max_requests に達するまでにほぼ同じ時間がかかり、そのためすべての子が基本的に同時に閉じられます。
この期間中、nginx は処理のために php ファイルを php-fpm に転送できないため、CPU が非常に低いレベルに低下し (SQL の実行はおろか、php を処理する必要もありません)、負荷が非常に低くなります。非常に高いレベルに上昇し (子を閉じてオンにし、nginx は php-fpm を待機します)、ネットワーク カードのトラフィックも非常に低くなります (nginx はクライアントに送信するデータを生成できません)
増加子の数を指定し、max_requests を 0 未満または比較的大きな値に設定します。 :
Open/usr/local/php/etc/php-fpm.conf
次の 2 つのパラメータを調整します (サーバーの実際の状況に応じて、大きすぎると機能しません) )
5120 600
その後、php-fpm を再起動します。
5. バッファ容量を増やす
nginx エラー ログを開き、「アップストリームからの応答ヘッダーの読み取り中に pstream が大きすぎるヘッダーを送信しました」 のようなエラー メッセージを見つけます。情報を確認したところ、nginx のバッファーにバグがあり、Web サイトのページ消費によって占有されているバッファーが大きすぎる可能性があることが一般的に考えられます。外国人の方が書かれた改造方法を参考にバッファ容量の設定を増やし、502問題を完全に解決しました。その後、システム管理者はパラメータを調整し、クライアント ヘッド バッファと fastcgi バッファ サイズの 2 つの設定パラメータだけを保持しました。
6. request_terminate_timeout
502 が静的ページ操作で一般的ではなく、主に一部の投稿またはデータベース操作中に発生する場合は、php- fpm.conf 設定:request_terminate_timeout
この値はmax_execution_time
で、fast-cgi の実行スクリプト時間です。
0s は閉じられています。これは、無期限に実行されることを意味します。 (着替えのときによく見ずに数値を変更してしまいました)
fastcgi の最適化では、この値を 5 秒間変更して効果を確認することもできます。
php-cgi プロセスの数が足りない場合、php の実行時間が長い場合、または php-cgi プロセスが停止した場合、502 エラーが発生します。
拡張知識:
Nginx 502 Bad Gateway は、要求された PHP-CGI が実行されたものの、何らかの理由 (通常はリソースの読み取りの問題) で PHP が実行されたことを意味します。 -CGI プロセスが不完全な実行のために終了する 一般的に、Nginx 502 Bad Gateway は php-fpm.conf の設定に関連しています。
php-fpm.conf には 2 つの重要なパラメータがあります。1 つは max_children、もう 1 つは request_terminate_timeout ですが、この値は普遍的ではないため、自分で計算する必要があります。インストール中および使用中に 502 問題が発生する場合、通常はデフォルトの php-cgi プロセスが 5 であるため、php-cgi プロセスが不足していることが原因である可能性があります。/usr/local/php/etc/php- を変更する必要があります。 fpm.conf max_children 値を適切に増やします。
計算方法は次のとおりです。
如果你的服务器性能足够好,且宽带资源足够充足,PHP脚本没有系循环或BUG的话你可以直接将 request_terminate_timeout设置成0s。0s的含义是让PHP-CGI一直执行下去而没有时间限制。而如果你做不到这一点,也就 是说你的PHP-CGI可能出现某个BUG,或者你的宽带不够充足或者其他的原因导致你的PHP-CGI假死那么就建议你给 request_terminate_timeout赋一个值,这个值可以根据服务器的性能进行设定。一般来说性能越好你可以设置越高,20分钟-30分 钟都可以。而max_children这个值又是怎么计算出来的呢?这个值原则上是越大越好,php-cgi的进程多了就会处理的很快,排队的请求就会很少。 设置max_children也需要根据服务器的性能进行设定,一般来说一台服务器正常情况下每一个php-cgi所耗费的内存在20M左右。
按照官方的答案,排查了相关的可能,并结合了网友的答案,得出了下面的解决办法。
1、查看php fastcgi的进程数(max_children值)
netstat -anpo | grep “php-cgi” | wc -l
5(假如显示5)
2、查看当前进程
top观察fastcgi进程数,假如使用的进程数等于或高于5个,说明需要增加(根据你机器实际状况而定)
3、调整/usr/local/php/etc/php-fpm.conf 的相关设置
max_children最多10个进程,按照每个进程20MB内存,最多200MB。request_terminate_timeout执行的时间为60秒,也就是1分钟。
推荐教程:nginx教程
以上がnginx がエラー 502 を報告した場合はどうすればよいですか?ソリューションの共有の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。