![NGINX 积累写入状态下的连接数是正常的吗?](https://linux22.com/image/654248/NGINX%20%E7%A7%AF%E7%B4%AF%E5%86%99%E5%85%A5%E7%8A%B6%E6%80%81%E4%B8%8B%E7%9A%84%E8%BF%9E%E6%8E%A5%E6%95%B0%E6%98%AF%E6%AD%A3%E5%B8%B8%E7%9A%84%E5%90%97%EF%BC%9F.png)
这是显示来自 nginx 的 stab_status 的连接数的图表,图中的下降是手动完成的服务器重启。
我觉得这种行为很奇怪,看起来像是某种泄漏。我认为有些连接挂起,应该关闭,但它们仍处于写入状态。
这是正常的吗?我应该采取行动吗?如果是,应该采取什么行动?
我尝试更改 nginx 的 keepalive,然后尝试更改一些内核设置,如下所示https://gist.github.com/perusio/2154235
但这种行为并没有改变。
该服务器是一个 VPS,具有一个可用处理器和 1024mb RAM。
EDIT1:版本
nginx 版本:由 gcc 4.8.2(Ubuntu 4.8.2-19ubuntu1)构建的 nginx/1.6.2 启用 TLS SNI 支持配置参数:--add-module=/root/ngx_pagespeed-release-1.9.32.3-beta --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-pcre-jit --with-http_ssl_module --without-mail_pop3_module --without-mail_smtp_module --without-mail_imap_module --without-http_scgi_module --with-ipv6 --with-http_stub_status_module --sbin-path=/usr/sbin/nginx --with-http_spdy_module
请注意,它运行 ngx_pagespeed
EDIT2:更多信息
Nginx 正在作为 uwsgi/django 应用程序的反向代理。我将监控 uwsgi 并发布结果,以便更好地了解 uwsgi 是否有事要做。
答案1
正如所描述的stub_status 模块文档,处于写入状态的连接意味着:
Writing
nginx 当前将响应写回客户端的连接数。
因此,您应该调查服务器的响应时间,并检查为什么客户端需要这么长时间才能获得 nginx 的回复并在之后关闭连接:网络速度慢、数据量大、分块传输编码、websockets……
答案2
如果您的某些服务器使用SPDY
或HTTP/2
,则您的问题根源在于此协议集成中的缺陷。您可以查看nginx 票证 #714。
目前状态是:
nginx 1.11.3 中至少有一个连接泄漏
HTTP/2
已修复,而 1.10.x 中尚未提供修复。请尝试使用 1.11.x。
答案3
这似乎是正常的行为,因为总会有客户端的连接不可靠,导致服务器的连接处于“发送”状态。他们不会再读取任何数据,但 Nginx 仍会等待,直到send_timeout
关闭连接之前。
这些也可能是恶意客户端故意这样做以耗尽服务器的可用连接和文件描述符的攻击,因此如果这成为一个真正的问题,您应该尝试降低上述值。