張超：又拍云系統(tǒng)開發(fā)高級(jí)工程師，負(fù)責(zé)又拍云?CDN?平臺(tái)相關(guān)組件的更新及維護(hù)。Github?ID:?tokers，活躍于?OpenResty?社區(qū)和?Nginx?郵件列表等開源社區(qū)，專注于服務(wù)端技術(shù)的研究；曾為?ngx_lua?貢獻(xiàn)源碼，在?Nginx、ngx_lua、CDN?性能優(yōu)化、日志優(yōu)化方面有較為深入的研究。

筆者曾今在更新 Nginx 服務(wù)的過程中發(fā)現(xiàn)舊的 Nginx worker 進(jìn)程退出非常緩慢(舊的 worker 進(jìn)程始終處在 "is shutting down" 的狀態(tài))，對(duì)此非常好奇，并對(duì)此展開了一些研究，本文將介紹 Nginx worker 進(jìn)程退出時(shí)的準(zhǔn)備步驟，延緩?fù)顺龅脑?#xff0c;并介紹對(duì)應(yīng)的解決辦法。

準(zhǔn)備退出

當(dāng) worker 進(jìn)程接收到 master 進(jìn)程要求它退出的指令后(詳見筆者另一篇文章：談?wù)?Nginx 信號(hào)集)，它便會(huì)開始為退出做準(zhǔn)備。

首先 worker 進(jìn)程會(huì)將正在監(jiān)聽的套接字從事件分發(fā)器(epoll，kqueue?等)中刪除，并將它們關(guān)閉，之后它將不再處理連接事件。

接著關(guān)閉所有的空閑連接，所謂的空閑連接，指的是當(dāng)前沒有請(qǐng)求正在使用的連接，例如 Nginx 和后端服務(wù)器維持的長(zhǎng)連接，或者 ngx_lua?Cosocket?對(duì)象底層的長(zhǎng)連接。

接著 worker 進(jìn)程會(huì)等待所有定時(shí)器過期(ngx_lua 提供給用戶使用的定時(shí)器比較特殊，在退出階段，它會(huì)提前過期，其他的 Nginx 內(nèi)部的定時(shí)器不會(huì)提前過期)，并同時(shí)處理尚未完成的事件。等事件處理完畢后， worker 進(jìn)程會(huì)調(diào)用所有模塊注冊(cè)的?exit_process?鉤子，最后退出。

退出被延緩

了解了 worker 進(jìn)程退出時(shí)的準(zhǔn)備過程后，我們可以深入分析為什么有的時(shí)候退出如此緩慢。

根據(jù)筆者目前的分析，目前有以下兩種情況會(huì)延緩 worker 進(jìn)程的退出：

• ngx_lua：在提前過期的定時(shí)器中使用?Cosocket

• Nginx http/2 實(shí)現(xiàn)上的一個(gè) 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)

當(dāng)然，這段代碼省略了一些錯(cuò)誤處理，但是用以解釋問題已經(jīng)足夠。這段代碼注冊(cè)了一個(gè)定時(shí)器，只要這個(gè)定時(shí)器運(yùn)行，就會(huì)創(chuàng)建一個(gè)?Cosocket?對(duì)象，然后去連接本機(jī)的?8080 端口，然后馬上將這個(gè)對(duì)象底層的連接置為 keep alive 狀態(tài)。

先說?connect?函數(shù)，如果和對(duì)端的連接不能一次性完成，ngx_lua 會(huì)為這次連接操作添加一個(gè)定時(shí)器，用以判斷連接超時(shí)，當(dāng)然這里是連接本機(jī)的端口，因此幾乎不會(huì)出現(xiàn)連接超時(shí)(對(duì)端異常除外)。

假如這里所要連接的對(duì)端處在公網(wǎng)，而且網(wǎng)絡(luò)狀況不理想的話，連接超時(shí)就有可能發(fā)生了，ngx_lua 默認(rèn)的?Cosocket?連接超時(shí)是 60s(lua_socket_connect_timeout)，這意味著這個(gè) worker 進(jìn)程會(huì)等待至少 60s，然后再退出。

同樣地，setkeepalive?也會(huì)為這條連接設(shè)置一個(gè)超時(shí)時(shí)間，默認(rèn)也是 60s(?lua_socket_keepalive_timeout) ，因此 worker 進(jìn)程也不得不等到這個(gè)定時(shí)器過期，或者某個(gè)時(shí)刻對(duì)端主動(dòng)關(guān)閉/異常關(guān)閉這條連接后，它才能夠退出。

讀者可能會(huì)有疑惑，之前講到 worker 進(jìn)程退出時(shí)會(huì)主動(dòng)關(guān)閉這些空閑的長(zhǎng)連接，那為什么這個(gè)示例還回造成 worker 進(jìn)程退出那么慢呢？即使是本機(jī)連接，也有可能出現(xiàn)無法一次完成連接(?EAGAIN) 的情況，此時(shí)當(dāng)前定時(shí)器的 Lua 協(xié)程就會(huì)被掛起，因此當(dāng) worker 進(jìn)程在關(guān)閉所有空閑連接的時(shí)候，這個(gè)示例里?setkeepalive?是還沒被執(zhí)行到的(甚至可能連接也沒有建立完成)，所以這條連接在當(dāng)時(shí)不是空閑的。直到后來某個(gè)時(shí)刻連接建立完成或者超時(shí)，當(dāng)時(shí)的 Lua 協(xié)程重新得到運(yùn)行機(jī)會(huì)，才會(huì)為這條連接添加定時(shí)器，置為空閑狀態(tài)。

另外一個(gè)阻礙 worker 進(jìn)程退出的原因來自于一個(gè) Nginx HTTP/2 模塊實(shí)現(xiàn)上的缺陷(見?Stale workers not exiting after reload (with HTTP/2 long poll requests))^[2]。這個(gè)問題在?Nginx/1.11.6?發(fā)布之后就修復(fù)了(見?Nginx: 5e95b9fb33b7)^[3]，1.11.6?之前的版本，如果一個(gè) HTTP/2 協(xié)議的客戶端一直在打開新的流，會(huì)導(dǎo)致這條連接上一直有事件在處理(當(dāng)然會(huì)伴隨著創(chuàng)建定時(shí)器)，這會(huì)導(dǎo)致 worker 進(jìn)程會(huì)一直無法退出，直到這條連接斷開。

Nginx 支持透明代理 websocket 連接。在 Nginx/1.13.7 版本以前，如果 worker 進(jìn)程存在一些 websocket 連接，而且連接上經(jīng)常有數(shù)據(jù)傳送，使得連接一直在正常工作的話，即使 worker 進(jìn)程收到來自 master 的退出指令，它也無法立刻退出，它需要等到這些連接出現(xiàn)異常、超時(shí)或者是某一端主動(dòng)斷開后，才能正常退出。

shutdown timeout

舊 worker 進(jìn)程不能及時(shí)退出，就會(huì)一直占用著系統(tǒng)資源(CPU、內(nèi)存和文件描述符等)，這對(duì)系統(tǒng)資源是一種浪費(fèi)，因此 Nginx/1.11.11 加入了一個(gè)新的指令(即?worker_shutdown_timeout，見?Core functionality)^[4]，允許用戶自定義 shutdown 超時(shí)時(shí)間，如果一個(gè) worker 在接收到退出的指令后經(jīng)過?worker_shutdown_timeout?時(shí)長(zhǎng)后還不能退出，就會(huì)被強(qiáng)制退出。

它的實(shí)現(xiàn)原理(Nginx: 97c99bb43737)^[5]也是通過創(chuàng)建定時(shí)器來實(shí)現(xiàn)的，一旦定時(shí)器過期， 所有連接都會(huì)被設(shè)置為 close 和 error 狀態(tài)(c->error = 1，c->close = 1)，這個(gè)標(biāo)志位事實(shí)上意味著 TCP 連接異常，Nginx 設(shè)計(jì)上對(duì)于這種狀態(tài)的連接，都會(huì)立刻結(jié)束對(duì)應(yīng)的所有請(qǐng)求、事件。通過這樣一個(gè)標(biāo)志位的設(shè)置，就達(dá)到了強(qiáng)制關(guān)閉所有連接、刪除所有定時(shí)器的目的，最終及時(shí)退出舊的 worker 進(jìn)程，釋放系統(tǒng)資源。

雖然這個(gè)功能早在 Nginx/1.11.11 就加入了，但是沒有完全覆蓋到所有的情況，例如上文所述的 websocket 連接的處理，那部分代碼并沒有判斷?c->close?和?c->error?的狀態(tài)位。所以仍然無法盡快終止這些 websocket 連接。直到 Nginx/1.13.7，這個(gè)問題才被修復(fù)。所以如果讀者們遇到類似的問題，可以考慮升級(jí) Nginx 至少到 1.13.7 版本。

[1]?issue 頁面:?http://link.zhihu.com/?target=https%3A//github.com/openresty/lua-nginx-module/issues/1279

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

[3]?修復(fù):?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 和位運(yùn)算

我眼中的 Nginx(二)：HTTP/2 dynamic table size update

我眼中的 Nginx(三)：Nginx 變量和變量插值

---

快 來 找 又 小 拍

---

---

推?薦 閱 讀

---

關(guān)于技術(shù)

第三屆萬物生長(zhǎng)大會(huì)在杭舉辦，又拍云再次躋身“準(zhǔn)獨(dú)角獸”行列

這樣介紹 CDN，老司機(jī)也能聽懂

聊聊常見的網(wǎng)絡(luò)攻擊

5G 網(wǎng)絡(luò)與 4G 相比，有什么區(qū)別？

---

?好看的人都「在看」啦???

總結(jié)

以上是生活随笔為你收集整理的nginx 超时时间_我眼中的 Nginx（四）：是什么让你的 Nginx 服务退出这么慢？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。