张超:又拍云系统开发高级工程师,负责又拍云 CDN 平台相关组件的更新及维护。Github ID: tokers,活跃于 OpenResty 社区和 Nginx 邮件列表等开源社区,专注于服务端技术的研究;曾为 ngx_lua 贡献源码,在 Nginx、ngx_lua、CDN 性能优化、日志优化方面有较为深入的研究。

笔者曾今在更新 Nginx 服务的过程中发现旧的 Nginx worker 进程退出非常缓慢(旧的 worker 进程始终处在 "is shutting down" 的状态),对此非常好奇,并对此展开了一些研究,本文将介绍 Nginx worker 进程退出时的准备步骤,延缓退出的原因,并介绍对应的解决办法。

准备退出

当 worker 进程接收到 master 进程要求它退出的指令后(详见笔者另一篇文章:谈谈 Nginx 信号集),它便会开始为退出做准备。

首先 worker 进程会将正在监听的套接字从事件分发器(epoll,kqueue 等)中删除,并将它们关闭,之后它将不再处理连接事件。

接着关闭所有的空闲连接,所谓的空闲连接,指的是当前没有请求正在使用的连接,例如 Nginx 和后端服务器维持的长连接,或者 ngx_lua Cosocket 对象底层的长连接。

接着 worker 进程会等待所有定时器过期(ngx_lua 提供给用户使用的定时器比较特殊,在退出阶段,它会提前过期,其他的 Nginx 内部的定时器不会提前过期),并同时处理尚未完成的事件。等事件处理完毕后, worker 进程会调用所有模块注册的 exit_process 钩子,最后退出。

退出被延缓

了解了 worker 进程退出时的准备过程后,我们可以深入分析为什么有的时候退出如此缓慢。

根据笔者目前的分析,目前有以下两种情况会延缓 worker 进程的退出:

  • ngx_lua:在提前过期的定时器中使用 Cosocket
  • Nginx http/2 实现上的一个 bug

第一种情况曾有人在 ngx_lua 的 issue 页面提出过( Cosocket :setkeepalive() in a a premature timer handler blocks Nginx worker from exiting · Issue #1279 · openresty/lua-Nginx-module)[1]。

比如 issue 中的示例代码:

ngx.timer.at(100, function ()
-- This blocks Nginx worker from exiting
    local timer_sock = ngx.socket.tcp()
    timer_sock:connect("127.0.0.1", 8080)
    timer_sock:setkeepalive()
end)

当然,这段代码省略了一些错误处理,但是用以解释问题已经足够。这段代码注册了一个定时器,只要这个定时器运行,就会创建一个 Cosocket 对象,然后去连接本机的 8080 端口,然后马上将这个对象底层的连接置为 keep alive 状态。

先说 connect 函数,如果和对端的连接不能一次性完成,ngx_lua 会为这次连接操作添加一个定时器,用以判断连接超时,当然这里是连接本机的端口,因此几乎不会出现连接超时(对端异常除外)。

假如这里所要连接的对端处在公网,而且网络状况不理想的话,连接超时就有可能发生了,ngx_lua 默认的 Cosocket 连接超时是 60s(lua_socket_connect_timeout),这意味着这个 worker 进程会等待至少 60s,然后再退出。

同样地,setkeepalive 也会为这条连接设置一个超时时间,默认也是 60s( lua_socket_keepalive_timeout) ,因此 worker 进程也不得不等到这个定时器过期,或者某个时刻对端主动关闭/异常关闭这条连接后,它才能够退出。

读者可能会有疑惑,之前讲到 worker 进程退出时会主动关闭这些空闲的长连接,那为什么这个示例还回造成 worker 进程退出那么慢呢?即使是本机连接,也有可能出现无法一次完成连接( EAGAIN) 的情况,此时当前定时器的 Lua 协程就会被挂起,因此当 worker 进程在关闭所有空闲连接的时候,这个示例里 setkeepalive 是还没被执行到的(甚至可能连接也没有建立完成),所以这条连接在当时不是空闲的。直到后来某个时刻连接建立完成或者超时,当时的 Lua 协程重新得到运行机会,才会为这条连接添加定时器,置为空闲状态。

另外一个阻碍 worker 进程退出的原因来自于一个 Nginx HTTP/2 模块实现上的缺陷(见 Stale workers not exiting after reload (with HTTP/2 long poll requests))[2]。这个问题在 Nginx/1.11.6 发布之后就修复了(见 Nginx: 5e95b9fb33b7)[3],1.11.6 之前的版本,如果一个 HTTP/2 协议的客户端一直在打开新的流,会导致这条连接上一直有事件在处理(当然会伴随着创建定时器),这会导致 worker 进程会一直无法退出,直到这条连接断开。

Nginx 支持透明代理 websocket 连接。在 Nginx/1.13.7 版本以前,如果 worker 进程存在一些 websocket 连接,而且连接上经常有数据传送,使得连接一直在正常工作的话,即使 worker 进程收到来自 master 的退出指令,它也无法立刻退出,它需要等到这些连接出现异常、超时或者是某一端主动断开后,才能正常退出。

shutdown timeout

旧 worker 进程不能及时退出,就会一直占用着系统资源(CPU、内存和文件描述符等),这对系统资源是一种浪费,因此 Nginx/1.11.11 加入了一个新的指令(即 worker_shutdown_timeout,见 Core functionality)[4],允许用户自定义 shutdown 超时时间,如果一个 worker 在接收到退出的指令后经过 worker_shutdown_timeout 时长后还不能退出,就会被强制退出。

它的实现原理(Nginx: 97c99bb43737)[5]也是通过创建定时器来实现的,一旦定时器过期, 所有连接都会被设置为 close 和 error 状态(c->error = 1,c->close = 1),这个标志位事实上意味着 TCP 连接异常,Nginx 设计上对于这种状态的连接,都会立刻结束对应的所有请求、事件。通过这样一个标志位的设置,就达到了强制关闭所有连接、删除所有定时器的目的,最终及时退出旧的 worker 进程,释放系统资源。

虽然这个功能早在 Nginx/1.11.11 就加入了,但是没有完全覆盖到所有的情况,例如上文所述的 websocket 连接的处理,那部分代码并没有判断 c->close 和 c->error 的状态位。所以仍然无法尽快终止这些 websocket 连接。直到 Nginx/1.13.7,这个问题才被修复。所以如果读者们遇到类似的问题,可以考虑升级 Nginx 至少到 1.13.7 版本。


[1] issue 页面: https://github.com/openresty/lua-nginx-module/issues/1279

[2] 缺陷: https://trac.nginx.org/nginx/ticket/1106

[3] 修复: http://hg.nginx.org/nginx/rev/5e95b9fb33b7

[4] 指令: http://nginx.org/en/docs/ngx_core_module.html#worker_shutdown_timeout

[5] 原理: http://hg.nginx.org/nginx/rev/97c99bb43737