nginx反向代理webman偶爾會出現104: Connection reset by peer

learner 2025-01-26

問題描述

nginx反向代理webman偶爾會出現

出現的很有規(guī)律。猜測跟monitor關閉內存超出的子進程有關。怎么解決。不應該先取消處理，再關閉進程嗎？

程序代碼

            if (preg_match('/VmRSS\s*?:\s*?(\d+?)\s*?kB/', $status, $match)) {
                $mem = $match[1];
            }
            $mem = (int) ($mem / 1024);
            if ($mem >= $memoryLimit) {
                posix_kill($pid, SIGINT);
            }

報錯信息

recv() failed (104: Connection reset by peer) while reading response header from upstream，

截圖報錯信息里報錯文件相關代碼

操作系統(tǒng)及workerman/webman等框架組件具體版本

webman v1.6.14 / workerman v5.0.0
linux php 安裝 php8.3 event擴展

 937  1 3

1個回答

walkor 2025-01-27

打賞

Connection reset by peer 一般是進程退出導致，從提供的信息中看不出來是哪里導致的退出，可以先把monitor關閉試下。
進程收到重啟信號會先處理業(yè)務，然后才關閉。但是有一些極端情況，例如業(yè)務執(zhí)行慢，被強制推退出。進程當前沒有處理請求，但是退出的時候剛好有請求發(fā)給當前進程。這些都會導致 Connection reset by peer

learner 2025-01-28

感謝。后面把內存限制提高，就沒有了。之前設置太低觸發(fā)關閉頻率太高了。
learner 2025-01-30

但是如果應對一些極端情況。想退出子進程。同時就得取消請求的分配。處理完當前請求。再結束。這樣才完整不是？畢竟不能因為小概率，而不去完整處理流程吧。
walkor 2025-01-30

極端情況不是能100%避免的，否則不叫極端情況了。例如業(yè)務就是很耗時，不可能無限等待，這時候kill掉進程就
Connection reset by peer了。
再比如服務端已經處理完當前收到的請求，但是服務端關閉進程那個時刻剛好有新的請求網絡傳輸的路上，進程退出也會 Connection reset by peer。
沒有取消請求分配的說法，客戶端連接連到A進程，那么這個連接的所有請求都會分配給A進程。連接關閉或者A進程退出，那么連接上所有傳輸中的請求都會丟失，然后 Connection reset by peer
learner 2025-02-01

好吧，學習了，還是得好好看文檔。我以為是accept了之后，把處理扔給進程，處理完后再返回給對應的socket不是？之前沒遇到這樣的。fpm下也沒遇到過這樣的。