web-dev-qa-db-ja.com

Nginx 502 BadGateway。バッファを増やすことで解決しました。どうして?

Drupalを実行するためにLEMPスタックをセットアップしているところです。 NginxとPHP-FastCGIをインストールしました。

Nginxは正常に機能しましたが、PHPを実行しようとすると、「502BadGateway」というエラーが発生しました。

簡単なグーグルが明らかにした: nginx502悪いゲートウェイ 、そしてバッファサイズを増やすことは問題を解決した。

_fastcgi_buffers 8 16k;
fastcgi_buffer_size 32k;
_

問題はなぜですか?

私の理解

前のリンクから、nginxがPHP-FastCGIにリクエストを送信していて、応答していなかったようです。これらのリクエストがタイムアウトになったのはどうですか?

Phpが複雑だったため、応答するのに十分な時間がありませんでした(そうではなく、phpinfo();でした)。バッファを増やしましたが、バッファを再度増やす必要があるのはいつですか?

15
Dominic Woodman

Nginxエラーログを確認すると、おそらく次のメッセージが表示されます。
upstream sent too big header while reading response header from upstream

fastcgi_buffersは、FastCGIアップストリームの応答に使用されるバッファセグメントの数とメモリサイズを設定します。

ドキュメントに示されているデフォルト値:
fastcgi_buffers 8 4k|8k;
ここで、デフォルトのバッファサイズはオペレーティングシステムのPAGESIZEと同じです。
getconf PAGESIZEを使用すると、現在のメモリページサイズを取得できます。

たとえば、Ubuntu 14.01では、デフォルトのPAGESIZEは4KBです。つまり、それぞれ4KBの8つのセグメントがあります。合計は32KBです。 FastCGIの応答がこの数を超えているため、応答コード502 - server receivedが返されます。

良い説明ではありませんが、理解を深めるのに役立つと思います。

9
antonbormotov

実際、問題はfastcgi_buffer_sizeにのみ直接関係しています。これは、応答からのHTTPヘッダーのみを保持する非常に特殊なバッファーです。

アプリケーションが大量のSet-Cookieヘッダー(またはHTTPヘッダーの合計サイズに寄与する他の何か)を出力する場合、ここでのデフォルトのバッファーサイズは十分でない可能性があり、それを増やす必要があります。

howを増やす必要があることを理解するには、私の超詳細な記事を読むことができます ここ -それはproxy_buffer_sizeについてですただし、fastcgi_バッファは非常によく似た動作をします。本質的なコマンドを引用するには:

curl -s -w \%{size_header} -o /dev/null https://example.com

適切なURLに対してテストし、必要に応じて-Hを介してリクエストヘッダーを追加してください。

これにより、ヘッダーサイズがバイト単位で表示されます。次に、結果の値を4k(メモリページの一般的なサイズ)に揃える必要があります。

だからあなたが得たなら、例えば14342バイトの場合、以下を設定する必要があります。

fastcgi_buffer_size 16k;

トリッキーな部分はありませんが、このバッファサイズを増やすときは、fastcgi_buffer_sizeまたはfastcgi_busy_buffers_sizeのいずれかを増やす必要があるという事実(== --- ==)NGINXが後者のデフォルト値を使用/計算する方法のため。

いずれにせよ、これらのバッファーを高く設定しすぎないで、アプリに固有の計算を使用してください。これらのバッファは接続ごとに使用されるため、任意に高い値はRAMに適していません。

1