私たちのアプリケーションの構成では、nginx は の前でリバース プロキシとして機能しますgunicorn。
私たちのアプリケーションは、一般的に言えば、フロントエンドのリクエストに対して小さな応答で応答しますが、一部のエンドポイントは 1 つのメモリ ページ (4K) より大きい応答を生成します。
これが起こると、nginx は次の警告をログに記録します。
an upstream response is buffered to a temporary file
/path/to/nginx/proxy_temp/4/86/0000000864 while reading upstream,
client: 1.2.3.4, server: api.ourdomain.com, request: "GET /pdf/..."
私たちのnginxログはこの警告で溢れてしまいます。私が知る限り、この警告をログから消す唯一の解決策は、悪い解決策:
nginx を
proxy_max_temp_file_size0 に設定できます。つまり、基本的には、大きめの応答のバッファリングを無効にします。これにより、ファイルへのバッファリングが停止しますが、大きな応答を生成するエンドポイント (1 ～ 2 MB の応答を作成する PDF 生成エンドポイントなど) の場合、消費の遅いクライアントが対応する gunicorn ワーカーを停止させることになります... 実際、N 個の gunicorn ワーカーがある場合、低速ネットワーク接続の背後で PDF を生成するクライアントが N 個あれば、アプリケーションがダウンします...4K (つまり 1 メモリ ページ) 以上に増やすことができます
proxy_buffer_size。これは nginx のパフォーマンスに重大な影響を与えることは間違いありません。応答の 70% は実際に 4K に収まり、nginx に割り当てを強制することになります... 何ですか? 時々発生する PDF 生成要求に備えるためだけに、それぞれに 2MB のバッファーを割り当てるのですか? 編集: 実際、これはまったくオプションではありません - Michael (下記) は、許可される値は 4K と 8K のみであるとコメントしています。オフにすることもできます
proxy_bufferingが、それは最初の解決策と同じくらい悪いです (遅いクライアント => 死)。
本質的に、nginx は、応答が大きい場合にファイルに一時的にバッファリングするという、私たちが望んでいることに関するログを大量に出力します。
これを実際には警告ではないものとして「マーク」することで、ログが溢れるのを止めたいだけです (なぜこれが警告なのかさえわかりません - これはどのような「悪いこと」について警告しているのでしょうか?)
nginxのソースコードを編集して再コンパイルする以外に、私が見逃している解決策はありますか?
答え1
これは、Nginx の error_log ディレクティブのログ レベルの結果です。
https://www.nginx.com/resources/admin-guide/logging-and-monitoring/
error_log logs/error.log warn;
警告、エラー クリティカル、アラート、緊急レベルのメッセージが記録されます。
エラー ログのデフォルト設定はグローバルに機能します。これを上書きするには、メイン (最上位) 構成コンテキストに error_log ディレクティブを配置します。メイン コンテキストの設定は、常に他の構成レベルに継承されます。error_log ディレクティブは、http、ストリーム、サーバー、および場所レベルでも指定でき、上位レベルから継承された設定を上書きします。
バッファリングに関する行は警告レベルです:
[warn] 30055#0: *1428 an upstream response is buffered to a temporary file
したがって、エラー ログ レベルが警告に設定されていないことを確認すると (つまり、デフォルトのままにするか、レベルを下げると)、その警告は表示されなくなります。以下のいずれかの解決策を実行すると、警告が抑制されます。
デフォルトのままにします (レベル「エラー」以上):
error_log logs/error.log;
同じこと：
error_log logs/error.log error;
しきい値を を超えて 、 、 まで増やすこともできerrorます。critalertemerg