这是一个显示来自nginx的stab_status的连接数的图表,图中的下拉列表是服务器重新手动完成的。

我觉得这种行为很奇怪,看起来有些泄漏。 我认为应该closures的挂钩关系,但他们保持书面状态。
这是正常的吗? 我应该采取行动吗? 如果是这样,在哪个方向?
我试着改变nginx的keepalive,然后像这样的一些内核设置https://gist.github.com/perusio/2154235
但是这种行为并没有改变。
该服务器是一个可用的处理器和1024MB内存的VPS。
编辑1:版本
nginx版本:由gcc 4.8.2构build的nginx / 1.6.2(Ubuntu 4.8.2-19ubuntu1)启用了TLS SNI支持的configuration参数:–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
编辑2:更多信息
Nginx正在作为uwsgi / django应用程序的反向代理。 我会监视uwsgi并发布结果,看看uwsgi有什么好做的。
这似乎是正常的行为,因为总会有客户端连接不可靠,导致服务器连接处于“发送”状态。 他们没有读取更多的数据,但是在closures连接之前,Nginx仍然会等待send_timeout 。
这些攻击也可能是恶意客户故意耗尽服务器可用连接和文件描述符的攻击,所以如果这成为真正的问题,则应该尝试降低上述值。
如stub_status模块文档所述,处于写状态的连接意味着:
Writingnginx将响应写回客户端的当前连接数。
所以你应该调查你的服务器响应时间,并检查为什么需要这么长的时间让客户获得nginx的答复,然后closures连接:networking速度慢,数据量大,分块传输编码,websocket …
如果某些服务器使用SPDY或HTTP/2 ,则问题的根源在于这些协议的集成缺陷。 你可以看看nginx票#714 。
目前的状况是:
在nginx 1.11.3中修复的
HTTP/2中至less有一个连接泄漏,并且该修补程序在1.10.x中尚不可用。 请尝试1.11.x。