nginx - 超時後超級工作者終止

我打算使用nginx來代理websockets。在執行nginx reload/HUP時，我明白nginx會等待舊的工作進程停止處理所有請求。然而，在websocket連接中，由於連接持久，這可能不會發生很長時間。是否有一個選項/路線圖在重新加載超時後強制殺死舊工作進程？nginx - 超時後超級工作者終止

參考文獻：

http://nginx.org/en/docs/control.html

http://forum.nginx.org/read.php?21,247573,247651#msg-247651

感謝

來源

2015-09-10 dux2

除非你有兩種解決方案：proxy_read_timeout 1D或ping消息來保持連接，Nginx的關閉在60秒否則連接。這個默認值是由一個原因選擇的。

看看Nginx的核心開發者says：

有proxy_read_timeout（http://nginx.org/r/proxy_read_timeout）這也適用於WebSocket連接。如果您的後端長時間不發送任何東西，您必須將其碰撞。或者，您可以配置您的後端定期發送websocket ping幀以重置超時（並檢查連接是否仍爲活動狀態）。

說了這麼多也不應該使用USR2 +的退出信號的組合，通常用來當你優雅重啓Nginx的同時二進制升級阻止你。 Nginx主/輔助進程極少消耗超過50MB的內存，因此保持多個主控並不是那麼昂貴。 USR2有助於分配新的主人併產生其工人，然後優雅地關閉老工人和主人。

來源

2015-09-10 09:17:24 Anatoly

如果確實存在來自後端服務器的定期ping，則連接將不會終止。然而，在你回答之後再次閱讀「Controlling nginx」文檔後，我想在將HUP發送給主nginx並等待幾分鐘後，我可以簡單地將TERM（快速關閉）發送給仍然活着的老員工，以終止它們。 – dux2

是的，USR2信號會分出開始爲新客戶端提供服務的新主服務器，然後，如果由於打開的連接而無法正常關閉，則需要先執行QUIT到舊主服務器，然後再執行INT或TERM信號。 – Anatoly

爲什麼建議使用USR2而不使用HUP，這樣可以在不產生新主人的情況下爲新員工分流？ – dux2

nginx - 超時後超級工作者終止

回答

相關問題