nginx反向代理webman偶爾會(huì)出現(xiàn)
出現(xiàn)的很有規(guī)律。猜測(cè)跟monitor關(guān)閉內(nèi)存超出的子進(jìn)程有關(guān)。怎么解決。不應(yīng)該先取消處理,再關(guān)閉進(jìn)程嗎?
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,
webman v1.6.14 / workerman v5.0.0
linux php 安裝 php8.3 event擴(kuò)展
Connection reset by peer 一般是進(jìn)程退出導(dǎo)致,從提供的信息中看不出來(lái)是哪里導(dǎo)致的退出,可以先把monitor關(guān)閉試下。
進(jìn)程收到重啟信號(hào)會(huì)先處理業(yè)務(wù),然后才關(guān)閉。但是有一些極端情況,例如業(yè)務(wù)執(zhí)行慢,被強(qiáng)制推退出。進(jìn)程當(dāng)前沒(méi)有處理請(qǐng)求,但是退出的時(shí)候剛好有請(qǐng)求發(fā)給當(dāng)前進(jìn)程。這些都會(huì)導(dǎo)致 Connection reset by peer
但是如果應(yīng)對(duì)一些極端情況。想退出子進(jìn)程。同時(shí)就得取消請(qǐng)求的分配。處理完當(dāng)前請(qǐng)求。再結(jié)束。這樣才完整不是?畢竟不能因?yàn)樾「怕?,而不去完整處理流程吧?/p>
極端情況不是能100%避免的,否則不叫極端情況了。例如業(yè)務(wù)就是很耗時(shí),不可能無(wú)限等待,這時(shí)候kill掉進(jìn)程就
Connection reset by peer
了。
再比如服務(wù)端已經(jīng)處理完當(dāng)前收到的請(qǐng)求,但是服務(wù)端關(guān)閉進(jìn)程那個(gè)時(shí)刻剛好有新的請(qǐng)求網(wǎng)絡(luò)傳輸?shù)穆飞?,進(jìn)程退出也會(huì) Connection reset by peer
。
沒(méi)有取消請(qǐng)求分配的說(shuō)法,客戶(hù)端連接連到A進(jìn)程,那么這個(gè)連接的所有請(qǐng)求都會(huì)分配給A進(jìn)程。連接關(guān)閉或者A進(jìn)程退出,那么連接上所有傳輸中的請(qǐng)求都會(huì)丟失,然后 Connection reset by peer
好吧,學(xué)習(xí)了,還是得好好看文檔。我以為是accept了之后,把處理扔給進(jìn)程,處理完后再返回給對(duì)應(yīng)的socket不是?之前沒(méi)遇到這樣的。fpm下也沒(méi)遇到過(guò)這樣的。