事件起因

事情起因于公司一位同事在內(nèi)部郵件組中post了一個(gè)問(wèn)題，一個(gè)使用了go1.8.3寫(xiě)的業(yè)務(wù)程序跑了一段時(shí)間后出現(xiàn)部分goroutine卡在等待一個(gè)鎖ForkLock的現(xiàn)象，同事認(rèn)為這是go1.8.3的bug，升級(jí)到go1.10后沒(méi)有再重現(xiàn)。為了搞清楚這個(gè)事情，同事在github上發(fā)了issue https://github.com/golang/go/issues/26836，期間也做了很多重現(xiàn)的嘗試，但并未重現(xiàn)。

我瀏覽了一下出現(xiàn)該問(wèn)題的業(yè)務(wù)代碼，大概的使用方式是父進(jìn)程調(diào)用os/exec下的Command開(kāi)子進(jìn)程執(zhí)行shell命令。Command后面會(huì)調(diào)用golang封裝的forkExec來(lái)開(kāi)子進(jìn)程并執(zhí)行命令，forkExec使用了ForkLock。

問(wèn)題分析

ForkLock 的存在是為了避免下面的情況：在有多個(gè)goroutine同時(shí)fork exec的情況下, 為了子進(jìn)程只繼承它需要的文件描述符，需要在父進(jìn)程在創(chuàng)建這些文件描述符的時(shí)候加上O_CLOEXEC標(biāo)志，這樣在子進(jìn)程中這些描述符是關(guān)閉的，子進(jìn)程按需把自己需要繼承的描述符打開(kāi)即可。

Linux在2.6.27之后，打開(kāi)文件或者管道，和設(shè)置O_CLOEXEC是一個(gè)原子操作，因此問(wèn)題不大，但golang對(duì)內(nèi)核版本的要求是2.6.23及以上，另外Unix系統(tǒng)中，open和設(shè)置O_CLOEXEC是兩個(gè)操作，如果在兩個(gè)操作之間發(fā)生fork, 子進(jìn)程就可能繼承它不需要的文件描述符，因此需要加鎖。重點(diǎn)看下forkExec時(shí)候的源代碼：

從問(wèn)題的現(xiàn)象看，肯定是某goroutine在forkExecPipe或者forkAndExecInChild這兩步卡住了，鎖沒(méi)釋放，因此有些goroutine一直拿不到鎖，饑餓致死。forkExecPipe***調(diào)用的是內(nèi)核pipe2, forkAndExecInChild***調(diào)用的是內(nèi)核clone和exec。

原因猜測(cè)

pipe2是一個(gè)快速系統(tǒng)調(diào)用，因此可能block的系統(tǒng)調(diào)用是clone和exec, 加上在go1.10上這個(gè)問(wèn)題沒(méi)有重現(xiàn)，對(duì)比go1.8代碼和go1.9在forkAndExecInChild函數(shù)上的差異:

go1.8

go1.9

go1.9增加了CLONE_VFORK和CLONE_VM 。只帶SIGCHILD的clone可以認(rèn)為類(lèi)似于fork(***都是調(diào)用do_fork), fork的問(wèn)題是，在父進(jìn)程占用內(nèi)存越大性能越差，具體可以看這個(gè)鏈接：https://bugzilla.redhat.com/show_bug.cgi?id=682922

這個(gè)case 2011年提出，今年7月還在更新，這個(gè)case反饋的問(wèn)題是，盡管Linux kernel 引入copy-on-write機(jī)制，但fork的時(shí)候依然要拷貝頁(yè)表，進(jìn)程虛擬內(nèi)存越大，需要拷貝的頁(yè)表項(xiàng)越多，因此fork越慢。Golang的討論組有人測(cè)試過(guò)，heap size在2G的情況下，fork耗時(shí)可以到毫秒級(jí)別, 正常是及幾十微秒，上千倍差距。

Go1.9加上這兩個(gè)參數(shù)是為了讓子進(jìn)程和父進(jìn)程共享內(nèi)存，相當(dāng)于調(diào)用vfork, 不需要拷貝頁(yè)表, 加快創(chuàng)建速度，從測(cè)試效果看，穩(wěn)定在幾十微妙。

所以一個(gè)合理的猜測(cè)是，在低于go1.9版寫(xiě)的程序中，當(dāng)程序內(nèi)存占用足夠大，而且創(chuàng)建進(jìn)程頻率足夠頻繁，會(huì)導(dǎo)致ForkLock長(zhǎng)時(shí)間等待。

實(shí)驗(yàn)論證

我用go1.8.3寫(xiě)了一個(gè)測(cè)試程序，在2核4G的虛擬機(jī)(kernel 3.10.0-693.17.1.el7.x86_64)下測(cè)試。

在外部每隔10秒，給這個(gè)程序發(fā)SIGUSR1信號(hào)，打印運(yùn)行時(shí)堆棧，運(yùn)行一段時(shí)間后，部分goroutine獲取ForkLock的時(shí)間越來(lái)越長(zhǎng)。見(jiàn)下面兩圖：

而在go1.9及以上版本上并未出現(xiàn)上述情況，這個(gè)結(jié)果我覺(jué)得已經(jīng)可以說(shuō)明問(wèn)題。升級(jí)版本到go1.9及以上版本可以解決該問(wèn)題。

寫(xiě)在***

vfork是為了解決fork拷貝頁(yè)表項(xiàng)導(dǎo)致的性能問(wèn)題, 而且大部分場(chǎng)景fork之后是調(diào)用exec，exec要把所有頁(yè)表刪除重置新的頁(yè)表, 實(shí)在沒(méi)必要再拷貝頁(yè)表項(xiàng)。但由于vfork父子進(jìn)程共享內(nèi)存，所以使用要很小心，如果子進(jìn)程修改某個(gè)變量，會(huì)影響到父進(jìn)程，而且kernel會(huì)掛起父進(jìn)程，讓子進(jìn)程先執(zhí)行，這些限制基本限制vfork只適合跟exec的場(chǎng)景，不如fork通用。

正因?yàn)関fork的使用需要小心，因此go1.9準(zhǔn)備加入vfork發(fā)布之前，有人提出代碼不夠健壯，因?yàn)閞awVforkSyscall返回之后，在父進(jìn)程段還執(zhí)行指令，這樣子進(jìn)程有機(jī)會(huì)破壞雙方的共享?xiàng)?，因此提了一個(gè)commit去讓rawVforkSyscall在返回后，在父進(jìn)程段什么都不做直接return，解決這個(gè)互相影響，如圖所示：

如有興趣深入了解，可以看下這個(gè)commit 的review，Rob Pike等人都有發(fā)言。

https://go-review.googlesource.com/c/go/+/46173