在我们的应用程序配置中,Nginx在gunicorn前充当反向代理.
我们的应用程序回复前端请求,一般来说,响应很小……但是一些端点生成的响应大于一个内存页面(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_size设置为0 – 基本上禁用缓冲大数据响应.这将停止对文件的缓冲 – 但这也意味着对于生成大响应的端点(例如,生成1-2MB响应的PDF生成),缓慢消耗的客户端会阻止相应的gunicorn工作者…事实上,如果有是N个gunicorn工作者,它只会让N个客户在慢速网络连接后生成PDF,我们的应用程序将会崩溃…
>我可以将proxy_buffer_size增加到4K以上(一个内存页面,即).我很确定这会对Nginx性能产生严重影响 – 我们70％的响应确实适合4K,我们会强制Nginx分配……什么？每个缓冲区都有2MB缓冲区,只是为偶尔的PDF生成请求做好准备？编辑：事实上这根本不是一个选项 – 迈克尔(下图)评论说,唯一允许的值是4K和8K.
>我可以关闭proxy_buffering – 但这和第一个解决方案一样糟糕(慢客户端=>死亡).
本质上,Nginx将我们的日志充斥到我们想要的东西 – 当响应很大时临时缓冲到文件.
我们只是想阻止这个充斥我们的日志,通过“标记”它不是一个真正的警告(我甚至不确定为什么这是一个警告 – 什么“坏事”它警告我们？)
https://www.nginx.com/resources/admin-guide/logging-and-monitoring/
error_log logs/error.log warn;
messages of warn,error crit,alert,and emerg levels are logged.
The default setting of the error log works globally. To override it,place the error_log directive in the main (top-level) configuration context. Settings in the main context are always inherited by other configuration levels. The error_log directive can be also specified at the http,stream,server and location levels and overrides the setting inherited from the higher levels.
关于缓冲的那一行是在警告级别：
[warn] 30055#0: *1428 an upstream response is buffered to a temporary file
因此,如果您确保错误日志级别未设置为警告,即将其保留为默认值或减小它,则您将不再看到该警告.以下任何一种解决方案都会抑制它们：
保留默认值(级别’错误’及以上)：
error_log logs/error.log;
一样：
error_log logs/error.log error;
您还可以将阈值提高到超出错误范围,直至暴击,警报和紧急情况.
