我眼中的 Nginx（四）：是什么让你的 Nginx 服务退出这么慢？

张超：又拍云系统开发高级工程师，负责又拍云 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

《我眼中的 Nginx》系列：

我眼中的 Nginx（三）：Nginx 变量和变量插值
 我眼中的 Nginx（二）：HTTP/2 dynamic table size update
我眼中的 Nginx（一）：Nginx 和位运算