☰

アップストリーム応答は一時ファイルにバッファリングされます

tag-icon • tag-icon nginx reverse-proxy buffer
アップストリーム応答は一時ファイルにバッファリングされます

かなり大きくて遅い (複雑なデータ、複雑なフロントエンド) Web アプリケーションをビルドして、リバース プロキシとしてRoR提供しています。エラー ログを見ると、次のようなエントリがいくつか見つかります。Pumanginxnginx

2014/04/08 09:46:08 [warn] 20058#0: *819237 an upstream response is buffered to a temporary file 
    /var/lib/nginx/proxy/8/47/0000038478 while reading upstream, 
    client: 5.144.169.242, server: engagement-console.foo.it, 
    request: "GET /elements/pending?customer_id=2&page=2 HTTP/1.0", 
    upstream: "http://unix:///home/deployer/apps/conversationflow/shared/sockets/puma.sock:/elements/pending?customer_id=2&page=2", 
    host: "ec.reputationmonitor.it", 
    referrer: "http://ec.foo.it/elements/pending?customer_id=2&page=3"

異なるユーザーや異なるユーザー操作に対してページが同じままである可​​能性は非常に低く、応答をディスクにバッファリングすることが必要/有用であるとは思わないため、私はむしろ興味があります。

0 に設定することは知っていますproxy_max_temp_file_sizeが、少し扱いに​​くいように思えます (プロキシはバッファリングを試みますが、バッファリングするファイルがありません...どうすればもっと速くできるでしょうか)。

私の質問は次のとおりです:

  1. [warn] を削除して応答のバッファリングを回避するにはどうすればよいでしょうか? オフにするか、 0 にproxy_buffering設定する方がよいでしょうか? なぜでしょうか?proxy_max_temp_file_size

  2. 応答をバッファリングする場合nginx: バッファリングされた応答はいつ、誰に、なぜ提供されるのでしょうか?

  3. なぜデフォルトでオンにnginxなっていてproxy_buffering、実際に応答をバッファリングすると [警告] が表示されるのでしょうか?

  4. 応答によってそのオプションがトリガーされるのはいつですか? 応答の提供に数秒 (何秒?) かかるのはいつですか? これは構成可能ですか?

TIA、ngw。

答え1

  1. [warn] を削除して応答のバッファリングを回避するにはどうすればよいでしょうか? proxy_buffering をオフにするか、proxy_max_temp_file_size を 0 に設定する方がよいでしょうか? なぜでしょうか?

proxy_max_temp_file_size削除するには0に設定する必要があります。このproxy_bufferingディレクティブは警告とは直接関係ありません。バッファリングを完全に停止するにはオフにすることができますが、一般的には推奨されません（必要な場合を除く）。彗星）。

  1. nginx が応答をバッファリングする場合、バッファリングされた応答はいつ、誰に、なぜ提供されるのでしょうか?

応答はすぐに提供されますが、クライアントの接続速度は通常はるかに遅いため、アプリケーションによって生成される応答データをすぐに消費することはできません。Nginx は、アプリケーションをできるだけ早く解放するために、応答全体をバッファリングしようとします。

参照:http://aosabook.org/en/nginx.html

  1. nginx がデフォルトで proxy_buffering をオンにして、実際に応答をバッファリングすると [警告] を表示するのはなぜですか?

すでに述べたように、はproxy_buffering警告とは直接関係ありません。これは通常、最適化されたプロキシ操作に必要であり、これをオフにするとパフォーマンスとスループットが低下します。

Nginx は、応答が設定されたメモリ バッファに収まらない場合にのみ警告します。問題がなければ、警告を無視できます。

  1. 応答によってそのオプションがトリガーされるのはいつですか? 応答の提供に数秒 (何秒?) 以上かかる場合ですか? これは構成可能ですか?

メモリ バッファがいっぱいになるとトリガーされます。ドキュメントを参照してください。メカニズム全体が説明されています。http://nginx.org/r/proxy_max_temp_file_size

メモリ バッファを増やす必要がある場合があります。

答え2

次の構成は私のサーバーでは正常に動作します。

proxy_buffers 16 16k;  
proxy_buffer_size 16k;

答え3

静的コンテンツの場合、nginx sendfileコマンドが役に立つかもしれません。

https://docs.nginx.com/nginx/admin-guide/web-server/serving-static-content/

sendfile を有効にする:

デフォルトでは、NGINX はファイル送信を自ら処理し、送信前にファイルをバッファにコピーします。sendfile ディレクティブを有効にすると、データをバッファにコピーする手順がなくなり、あるファイル記述子から別のファイル記述子にデータを直接コピーできるようになります。1 つの高速接続がワーカー プロセスを完全に占有するのを防ぐには、sendfile_max_chunk ディレクティブを使用して、1 回の sendfile() 呼び出しで転送されるデータの量を制限します (この例では 1 MB)。

location /mp3 {
    sendfile           on;
    sendfile_max_chunk 1m;
    #...
}

答え4

これらをnginx.confまたは仮想ホスト設定ファイルのコンテキストに追加します（http、サーバ、位置):

proxy_max_temp_file_size 10240m;
proxy_buffers 240 240k;
proxy_busy_buffers_size 240k;
proxy_buffer_size 240k;

状況に応じて値を設定できますが、値は互いにバランスが取れている必要があります (バッファ ディレクティブに異なる数値を使用しないでください)。

私も同じ問題を抱えており、IO、SQL、PHP プロセスが重く長時間かかるスクリプトでこれらの構成をテストしたところ、問題なく動作しました。

関連情報