問題タブ [http-status-code-504]

ELB は時折 504 をクライアントにすぐに返します (1 秒以内)。問題は、それが完全にランダムであることです。リクエストをすぐに繰り返すと、正常に機能します。

誰もがこれについて同じ問題や考えを持っていますか?

Restletを使用して毎秒サーバーにリクエストを送信するようにJavaプログラムをセットアップしていますが、毎週同じ時間に、プログラムを実行している時間内に約1分間メンテナンスを行います。

その結果、504 エラーが 2 回発生し、次に 503 エラーが発生し、何らかの理由でプログラムの実行が停止します。503エラーの後、続行しません。それは言います：

回復可能なエラーが検出されました (503)、2000 ミリ秒後に再試行します

しかし、再試行しません。毎秒サーバーにリクエストし続けるように設定したので（「回復可能なエラー」に達すると停止します）、プログラムに504および503エラーを無視させ、何事もなかったかのように進みます。

サーバーが WHM/Cpanel で動作し、長時間の php スクリプトを実行すると、サーバーに「504 ゲートウェイ タイムアウト」が表示されます。

しかし、サーバー上にnginxファイルが見つかりません...試しました:

find / -name nginx.conf

nginxはどこですか

ps -lA | awk '$12 == "?" {印刷 $4、$14}'

nginx -V

OS：CentOS

クラウドフレアを使用しているサイト

先日、nginx Web サーバーが php スクリプトの処理を停止し、504 ゲートウェイ タイムアウトが発生するという問題に遭遇しました。ポート9000でphp5-fpmをセットアップしました。

実行するとnetstat | grep 9000、次の結果が得られました。異なるポート番号で何百回も

そして、彼らはまったく片付けられていないようでした。サーバーに大量のトラフィックがヒットしたか、どこかでスクリプトが間違っていた可能性があります。サーバーから優先度の低いサイトの束をシャットダウンし（約10個の異なるnginxサイト構成ファイルを実行しています）、物事は再び動作していますが、phpページへのリクエストごとにnetstatがそれらの9000-> 37XXXポートの1つを報告し、ページはほぼ瞬時にクライアントに返されますが、60 秒間開いたままになります。

60秒間開いたままにする理由はありますか? または、接続が再利用されないのはなぜですか? 何かが正しく構成されていませんか?

サイトの 1 つに再び大量のトラフィックが発生すると、すべての接続が再び拘束され、504 ゲートウェイ タイムアウトが再び表示されるのではないかと心配しています。悪いphpスクリプトではありません。

職場のデバイスからの大規模なデータ セットを分析し、Plotly を使用してデータをグラフ化するために作成した小さなプログラムがあります。最近までうまく機能していましたが、先週、データをグラフ化するときに 504 ゲートウェイ タイムアウト サーバー エラーが発生しました。コードのグラフ部分を変更してみましたが、コードは何も変更されていません。python/anaconda の両方の再インストールと、plotly python ライブラリのインストールと更新を試みました。3 つの異なるアカウントを使用して、plotly の API 資格情報を再初期化しましたが、成功しませんでした。これまでのところ、すべての努力にもかかわらずエラーは解決されていませんが、Python コンソールを使用するとプロットをグラフ化できます。

これに関するヘルプは非常に役立ちます。必要に応じて、コードの一部を投稿できます。以下は、コンソールが出力するエラーです。

ファイル "NKDA_2.1.py"、51 行目、thisPulseCount、thisArcCount、thisMaxCurrent = FH.processFile(procedureID, currentProcedure, resultsFolder) ファイル "C:\Users\cellison\Documents\Data Analysis\fileHandling.py"、97 行, in processFile unique_url = py.plot(fig, filename=graphName) ファイル "C:\Users\cellison\AppData\Local\Continuum\Anaconda\lib\site-packages\plotly\plotly\plotly.py", 行 262, in plot res = _send_to_plotly(figure, **plot_options) ファイル "C:\Users\cellison\AppData\Local\Continuum\Anaconda\lib\site-packages\plotly\plotly\plotly.py"、1421 行目、_send_to_plotly r .raise_for_status() ファイル "C:\Users\cellison\AppData\Local\Continuum\Anaconda\lib\site-packages\requests\models.py"、851 行目、raise_for_status で HTTPError(http_error_msg, response=self) リクエストを発生させます。exceptions.HTTPError: 504 サーバー エラー: GATEWAY_TIMEOUT

RHEL 6.6 の Web サーバー Varnish + Nginx + FastCGI (php-fpm) で次のスタックを実行しています。

毎回異なる結果セットを持つ動的な Web サイトであり、Google でインデックス化された約 200 万の URL があります。

• nginx/1.5.12 および PHP 5.3.3 で実行されます (最新の nginx および PHP にすぐにアップグレードされます)。
• Nginx は、ポート 9000 で同じサーバー上でローカルに実行されている php-fpm に接続します

一部のページで断続的に 504 ゲートウェイ タイムアウトが発生しますが、解決できません。504 を与える URL は、しばらくすると正常に動作します。ログから 504 について知ることができましたが、任意の URL でランダムに発生し、しばらくすると機能するため、これを複製することはできませんでした。

私は開発者といくつかの議論をしましたが、彼によると、基礎となるphpスクリプトはほとんど何もせず、これほど長くはかからないはずです（120秒）が、それでも504ゲートウェイタイムアウトが発生します.

問題が発生した正確な場所を特定する必要があります。

• Nginxの問題ですか？
• php-fpm に問題がありますか?
• 基礎となるphpスクリプトに問題がありますか?
• nginx が php-fpm に接続できない可能性はありますか?
• への TCP/IP 接続の代わりに Unix ソケットを使用すると解決しますか?

URL は 504 で 120 秒後にタイムアウトします

以下は見られるエラーです: 2016/01/04 17:29:20 [エラー] 1070#0: *196333149 アップストリーム タイムアウト (110: 接続タイムアウト) アップストリームへの接続中に、クライアント: 66.249.74.95、サーバー: xxxx、リクエスト: "GET /Some/url HTTP/1.1"、アップストリーム: "fastcgi://127.0.0.1:9000"、ホスト: "example.com"

以前は 150 秒の fastcgi_connect_timeout で、RHEL 6.6 ではデフォルトの net.ipv4.tcp_syn_retries = 5 で 63 秒後に 502 ステータス コードが表示されていました。その後、net.ipv4.tcp_syn_retries = 6 を設定すると、127 秒後に 502 が返され始めました。

fastcgi_connect_timeout = 120 を設定すると、504 ステータス コードが返され始めました。このような高い値の fastcgi_connect_timeout が良くないことは理解しています。

正確に 504 を取得している理由を見つける必要があります (タイムアウトはわかっていますが、原因は不明です)。根本的な原因を突き止めて、完全に修正する必要があります。

問題の正確な場所を確認するにはどうすればよいですか?

すでに定義されているタイムアウトの一部を次に示します。

サーバー全体の nginx.conf の下:

• キープアライブ_タイムアウト 5;
• send_timeout 150;

特定の vhost.conf の下:

• proxy_send_timeout 100
• proxy_read_timeout 100
• プロキシ接続タイムアウト 100
• fastcgi_connect_timeout 120
• fastcgi_send_timeout 300
• fastcgi_read_timeout 300

タイムアウトにはさまざまな値が使用されるため、どのタイムアウトが正確にトリガーされたかを把握できます。

以下は sysctl.conf の設定の一部です:

• net.ipv4.ip_local_port_range = 1024 65500
• net.ipv4.tcp_fin_timeout = 10
• net.ipv4.tcp_tw_reuse = 1
• net.ipv4.tcp_syn_retries = 6
• net.core.netdev_max_backlog = 8192
• net.ipv4.tcp_max_tw_buckets = 2000000
• net.core.somaxconn = 4096
• net.ipv4.tcp_no_metrics_save = 1
• vm.max_map_count = 256000

コードの記述が不十分な場合は、nginx または php-fpm が原因ではなく、php コードの問題が原因で 504 が発生していることを開発者に通知する必要があります。Nginx または Php-fpm が原因である場合は、修正する必要があります。

前もって感謝します！

======

さらに更新：

2 つのケースがあります。

1. 504 @ 120 秒で以下のエラーが発生します:

2016/01/05 03:50:54 [エラー] 1070#0: *201650845 アップストリーム タイムアウト (110: 接続タイムアウト) アップストリームへの接続中に、クライアント: 66.249.74.99、サーバー: xxxx、要求: "GET /some /url HTTP/1.1"、アップストリーム: "fastcgi://127.0.0.1:9000"、ホスト: "example.com"

2. 504 @ 300 秒で、以下のエラーが発生します。

2016/01/05 00:51:43 [エラー] 1067#0: *200656359 アップストリームがタイムアウトしました (110: 接続がタイムアウトしました) アップストリームからの応答ヘッダーの読み取り中に、クライアント: 115.112.161.9、サーバー: 192.168.12.101、リクエスト: "GET /some/url HTTP/1.1"、アップストリーム: "fastcgi://127.0.0.1:9000"、ホスト: "example.com"

• php-fpm ログにエラーは見つかりませんでした。

• php-fpm プロセスの数も正常でした。他のリクエストが同時に正常に処理されたため、バックエンドが過負荷になっているようには見えません。

• 1 つの php-fpm プールのみが使用されています。通常、1 つの php-fpm マスター (親) プロセスとその他のスレーブ (子) プロセスは、5xx が観測された場合にのみ正常範囲にあります。php-fpm プロセスの数が大幅に増加することはなく、たとえ増加したとしても、サーバーには新しいプロセスをフォークしてリクエストを処理するのに十分な容量があります。