nginx 504 Gateway Time-outエラーチェック
3140 ワード
nginx 504 Gateway Time-outエラーチェック、レコード解決を繰り返しチェックした結果、この問題の原因はPHPのCURLにタイムアウト時間が設定されていないことであり、解決策はタイムアウト時間を設定したりnginxの構成を変更したりすれば解決できる.
不思議なサイトが応答を失ったことを覚えています.以前はnginxをエージェントバックエンドとして使用していたapacheがphpを実行してサービスを提供していた.apacheは不定期不定時間の出現でサービスが応答を失うことが多く、nginxは「504 Gateway Time-out」が現れてエラーログを見ても何も見えず、apacheのバグだと思っていた.(実はそうじゃなくて、次は理由になります).年を取ると振り回されないかもしれませんが、そのまま動かないで、監視ツールを使って、警報を受けるたびにapacheを再起動して無理に維持しています.やっとある日うんざりしました.phpを処理するのではないでしょうか.apacheを使わなくてもいいでしょう.怒ってソースインストールphp-fpmを使ってphp-fpmに移動してphpを実行します.phpをインストールして面倒ではありません.ソースのインストールは順調です.唯一必要なのはphp workerワークプロセスのログ出力phpエラーログを設定することです.
準備万端整ったら元のproxy_passをfastcgipassに変えればいい.upstream apachephp{
server www.jbxue.com:8080; #Apache1}....proxy_pass http://apachephp;
upstream phpに置き換えます{
server 127.0.0.1:9000;}...fastcgi_pass php;
apacheで走っていたphpをphp-fpmに移行して走ることができます.これで枕を高くして安心できると思っていましたが、移行が完了しても確かに問題はありませんでしたが、問題の根本的な原因がどこにあるのか分析しなければなりません.問題はやはりドアを探して、翌日nginxは504のgateway timeoutを報告しました.今回はapacheに何の用事もないでしょう.apacheはやっと関係を解消しました.それはまた、nginxとphp-fpmでnginxのエラーログを表示すると、[error]6695#0:*168438 upstream timed out(110:Connection timed out)while reading response header from upstreamが表示されます.
...request: "GET/kd/open.php?company=chinapost&number=PA24977020344 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.jbxue.com"
ここを見ると基本的にnginxの疑いは排除され、nginxはphp処理「GET/kd/open.php?company=chinapost&number=PA 24977020344 HTTP/1.1」を待っているタイムアウトで終了しました.すぐにphp-fpmを再起動します.問題がなくなり、サイトにアクセスできました.再びこのページにアクセスしても応答はありませんが、同時に別のページにアクセスするのは正常です.このページを何回かリフレッシュした後、サイト全体がbad gateway timeoutになりました.問題はこのphpスクリプトに縮小されました.netstat-napo|grep「php 5-fpm」|wc-l
php作業プロセスがプロファイルの上限10に達していることを確認すると、open.phpというスクリプトに引っかかっているような気がします.このスクリプトは何をしているのでしょうか.このスクリプトは速達情報を収集し、php_curlを使用しています.PHPスクリプトはphp.iniのプロファイルmax_execution_timeを超えると強制的に終了します.php.iniのmax_execution_timeは確かに配合されており、値は30です.万能googleが役に立ち、googleを繰り返した後、set_time_limit()関数と構成命令max_execution_timeはスクリプト自体の実行時間にのみ影響します.システム()の使用などのシステム呼び出し、ストリーム操作、データベース操作などのスクリプト実行の最大時間は含まれません.このスクリプトが実行された場合.www.jbxue.comとは、スクリプト実行時間に関係なく、スクリプト実行時間に他の操作が実行された場合、phpは呼び出しの結果を待機します.open.phpソースファイルを見てみると、やはり設定されていませんcurlのタイムアウト時間を設定します.次の2行を追加して再リフレッシュし、問題が解決しました.curl_setopt($ch,CURLOPT_CONNECTIMEOUT,10);//timeout on connect
curl_setopt($ch, CURLOPT_TIMEOUT, 10);//timeout on responseもちろん、この方法に加えてphp-fpmには、長い間結果のないプロセスを強制的に殺すためのパラメータも用意されていますが、このパラメータはデフォルトでは開いていません.php-fpmのプロファイルには、リクエストの終了時間がこの時間を超えるとkillされるパラメータrequest_terminate_timeoutを設定できます.また、パラメータrequもありますest_slowlog_timeoutは、スローリクエストログを記録するために使用されます.コマンドラインでphpを実行する場合は、このコードを使用します.
不思議なサイトが応答を失ったことを覚えています.以前はnginxをエージェントバックエンドとして使用していたapacheがphpを実行してサービスを提供していた.apacheは不定期不定時間の出現でサービスが応答を失うことが多く、nginxは「504 Gateway Time-out」が現れてエラーログを見ても何も見えず、apacheのバグだと思っていた.(実はそうじゃなくて、次は理由になります).年を取ると振り回されないかもしれませんが、そのまま動かないで、監視ツールを使って、警報を受けるたびにapacheを再起動して無理に維持しています.やっとある日うんざりしました.phpを処理するのではないでしょうか.apacheを使わなくてもいいでしょう.怒ってソースインストールphp-fpmを使ってphp-fpmに移動してphpを実行します.phpをインストールして面倒ではありません.ソースのインストールは順調です.唯一必要なのはphp workerワークプロセスのログ出力phpエラーログを設定することです.
準備万端整ったら元のproxy_passをfastcgipassに変えればいい.upstream apachephp{
server www.jbxue.com:8080; #Apache1}....proxy_pass http://apachephp;
upstream phpに置き換えます{
server 127.0.0.1:9000;}...fastcgi_pass php;
apacheで走っていたphpをphp-fpmに移行して走ることができます.これで枕を高くして安心できると思っていましたが、移行が完了しても確かに問題はありませんでしたが、問題の根本的な原因がどこにあるのか分析しなければなりません.問題はやはりドアを探して、翌日nginxは504のgateway timeoutを報告しました.今回はapacheに何の用事もないでしょう.apacheはやっと関係を解消しました.それはまた、nginxとphp-fpmでnginxのエラーログを表示すると、[error]6695#0:*168438 upstream timed out(110:Connection timed out)while reading response header from upstreamが表示されます.
...request: "GET/kd/open.php?company=chinapost&number=PA24977020344 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.jbxue.com"
ここを見ると基本的にnginxの疑いは排除され、nginxはphp処理「GET/kd/open.php?company=chinapost&number=PA 24977020344 HTTP/1.1」を待っているタイムアウトで終了しました.すぐにphp-fpmを再起動します.問題がなくなり、サイトにアクセスできました.再びこのページにアクセスしても応答はありませんが、同時に別のページにアクセスするのは正常です.このページを何回かリフレッシュした後、サイト全体がbad gateway timeoutになりました.問題はこのphpスクリプトに縮小されました.netstat-napo|grep「php 5-fpm」|wc-l
php作業プロセスがプロファイルの上限10に達していることを確認すると、open.phpというスクリプトに引っかかっているような気がします.このスクリプトは何をしているのでしょうか.このスクリプトは速達情報を収集し、php_curlを使用しています.PHPスクリプトはphp.iniのプロファイルmax_execution_timeを超えると強制的に終了します.php.iniのmax_execution_timeは確かに配合されており、値は30です.万能googleが役に立ち、googleを繰り返した後、set_time_limit()関数と構成命令max_execution_timeはスクリプト自体の実行時間にのみ影響します.システム()の使用などのシステム呼び出し、ストリーム操作、データベース操作などのスクリプト実行の最大時間は含まれません.このスクリプトが実行された場合.www.jbxue.comとは、スクリプト実行時間に関係なく、スクリプト実行時間に他の操作が実行された場合、phpは呼び出しの結果を待機します.open.phpソースファイルを見てみると、やはり設定されていませんcurlのタイムアウト時間を設定します.次の2行を追加して再リフレッシュし、問題が解決しました.curl_setopt($ch,CURLOPT_CONNECTIMEOUT,10);//timeout on connect
curl_setopt($ch, CURLOPT_TIMEOUT, 10);//timeout on responseもちろん、この方法に加えてphp-fpmには、長い間結果のないプロセスを強制的に殺すためのパラメータも用意されていますが、このパラメータはデフォルトでは開いていません.php-fpmのプロファイルには、リクエストの終了時間がこの時間を超えるとkillされるパラメータrequest_terminate_timeoutを設定できます.また、パラメータrequもありますest_slowlog_timeoutは、スローリクエストログを記録するために使用されます.コマンドラインでphpを実行する場合は、このコードを使用します.
$real_execution_time_limit = 60; //
if (pcntl_fork())
{
// some long time code which should be
// terminated after $real_execution_time_limit seconds passed if it's not
// finished by that time
}
else
{
sleep($real_execution_time_limit);
posix_kill(posix_getppid(), SIGKILL);
}