線上服務(wù)器出現(xiàn)一個詭異的問題，執(zhí)行任何命令都是報(bào)錯“fork:無法分配內(nèi)存”。這個問題最近出現(xiàn)的，前幾次重啟后解決的，但是每隔 2-3 天就會出現(xiàn)一次。

看到這個提示，大家的第一反應(yīng)肯定是懷疑內(nèi)存真的不夠了。但查看內(nèi)存占用卻發(fā)現(xiàn)根本沒有，內(nèi)存還空閑了一大把?。ǘ嘣噹状尾庞袡C(jī)會執(zhí)行成功一次）

參謀這個問題以后，幫出了三個思路。

• 1.是不是numa架構(gòu)下，進(jìn)程啟動的時候綁定了node，導(dǎo)致只有一個node里的內(nèi)存在起作用？

• 2.numa架構(gòu)下，如果所有內(nèi)存都插到一個槽，其它node就會沒內(nèi)存

• 3.查看下現(xiàn)在的進(jìn)(線)程數(shù)是多少，是不是超過最大限制了

在經(jīng)過一段時間的排查以后，問題順利解決。這里直接和大家匯報(bào)結(jié)論，前面關(guān)于 numa 內(nèi)存不足的猜測是錯誤的。真實(shí)的原因是上面第 3 個，這臺服務(wù)器上面的某幾個java進(jìn)程創(chuàng)建了太多的線程，導(dǎo)致了這個報(bào)錯的產(chǎn)生，并不真的是內(nèi)存不夠。

一、底層過程分析

這個問題中，Linux 報(bào)錯提示存在誤導(dǎo)人的地方。導(dǎo)致大家并沒有第一時間往進(jìn)程數(shù)上想。所以才有了這么復(fù)雜曲折的排錯過程，以至于在群里討論才得以解決。

于是我想深入到內(nèi)核里看看，報(bào)錯到底是如何提示出來這么一個不恰當(dāng)?shù)腻e誤提示的。然后順便咱們也來了解了解創(chuàng)建進(jìn)程的過程。

讀者的線上服務(wù)器的操作系統(tǒng)是 CentOS 7.8，我查了一下對應(yīng)的內(nèi)核版本是 3.10.0-1127。

【文章福利】小編推薦自己的Linux內(nèi)核技術(shù)交流群:【891587639】整理了一些個人覺得比較好的學(xué)習(xí)書籍、視頻資料共享在群文件里面，有需要的可以自行添加哦?。。。ê曨l教程、電子書、實(shí)戰(zhàn)項(xiàng)目及代碼)? ? ??

1.1 do_fork 剖析

在 Linux 內(nèi)核里，無論是創(chuàng)建進(jìn)程還是線程，都會調(diào)用到最核心的 do_fork 上來。在這個函數(shù)內(nèi)部，通過拷貝的方式來創(chuàng)建新的進(jìn)程（線程）所需要的內(nèi)核數(shù)據(jù)對象。

整個進(jìn)程創(chuàng)建的核心都是位于 copy_process 中，我們來看它的源碼。

通過以上代碼可以看出，Linux 內(nèi)核創(chuàng)建整個進(jìn)程內(nèi)核對象的創(chuàng)建過程都是通過分別調(diào)用不同的 copy_xxx 的方式來實(shí)現(xiàn)的，包括 mm 結(jié)構(gòu)體、包括 namespaces等等。

我們來重點(diǎn) alloc_pid 相關(guān)的這一段。在這一段中，目的是要申請一個 pid 對象出來。如果申請失敗就返回錯誤了。大家注意這段代碼的細(xì)節(jié)：無論 alloc_pid 返回的是何種類型的失敗，其錯誤類型都寫死的返回 -ENOMEM。。。 為了方便大家理解，我單獨(dú)把這段邏輯再展示一遍。

在準(zhǔn)備調(diào)用 alloc_pid 的時候，直接就先將錯誤類型設(shè)置成了 -ENOMEM(retval = -ENOMEM)，只要 alloc_pid 返回的不正確，都是將 ENOMEM 這個錯誤返回給上層。而不管 alloc_pid 內(nèi)存究竟是因?yàn)槭裁丛虍a(chǎn)生的錯誤。

我們來查看一下 ENOMEM 的定義。它代表的是 Out of memory 的意思。（內(nèi)核只是返回錯誤碼，應(yīng)用層再給出具體的錯誤提示，所以實(shí)際提示的是中文的“無法分配內(nèi)存”）。

不得不說。內(nèi)核的這個錯誤提示太成問題了。給使用者造成了很大的困惑。

1.2 導(dǎo)致 alloc_pid 失敗的原因

那我們接著再來詳細(xì)看看都有哪些情況下分配 pid 會失敗呢？來看 alloc_pid 的源碼

我們平時說的 pid 在內(nèi)核中并不是一個簡單的整數(shù)類型，而是一個小結(jié)構(gòu)體來表示的（struct pid），如下。

所以需要先到內(nèi)存中申請一塊內(nèi)存用來存儲這個小對象。第一種錯誤情況是如果內(nèi)存申請失敗，alloc_pid 會返回失敗。這種情況下確實(shí)是內(nèi)存問題，出錯后內(nèi)核返回 ENOMEM 無可厚非。

接著往下看第二種情況，alloc_pidmap 是要為當(dāng)前的進(jìn)程申請進(jìn)程號，就是我們平時所說的 PID 編號。如果申請失敗，也會返回錯誤。

對于這種情況來說，只是分配進(jìn)程編號出錯了，和內(nèi)存不夠用半毛錢的關(guān)系都沒有。但在這種情況下內(nèi)核卻會導(dǎo)致返回給上層的錯誤類型是 ENOMEM（Out of memory）。這實(shí)在是挺不合理的。

通過這里我們還額外學(xué)習(xí)到了另外一個知識！一個進(jìn)程并不只是申請一個進(jìn)程號就夠了。而是通過一個 for 循環(huán)去申請了多個。

假如說當(dāng)前創(chuàng)建的進(jìn)程是一個容器中的進(jìn)程，那么它至少得申請兩個 PID 號才行。一個 PID 是在容器命名空間中的進(jìn)程號，一個是根命名空間（宿主機(jī)）中的進(jìn)程號。

這也符合我們平時的經(jīng)驗(yàn)。在容器中的每一個進(jìn)程其實(shí)我們在宿主機(jī)中也都能看到。但是在容器中看到的進(jìn)程號一般是和在宿主機(jī)上看到的是不一樣的。比如一個進(jìn)程在容器中的 pid 是 5，在宿主機(jī)命名空間下是 1256。那么該進(jìn)程在內(nèi)核中的對象大概是如下這個樣子。

二、新版本是否有所改觀

接下來，我首先想到的可能是因?yàn)樵蹅冇玫膬?nèi)核版本太舊了。

所以我又到非常新的 Linux 5.16.11 翻了一翻，看看新版本是否有修復(fù)這個不恰當(dāng)?shù)奶崾尽?/p>

推薦一個工具：https://elixir.bootlin.com/ 。在這個網(wǎng)站上可以查看任意版本的 linux 內(nèi)核源碼。如果只是臨時看一下，用它非常的合適。

貌似看起來有戲，retval 不再寫死的是 ENOMEM 了，而是根據(jù) alloc_pid 實(shí)際的錯誤進(jìn)行了設(shè)置。我們再來看 alloc_pid 是不是正確地設(shè)置錯誤類型了呢？

當(dāng)我打開 alloc_pid 的源碼里，看到這一大段注釋的時候，我的心涼了半截。。。

我把這段注釋給大家大致翻譯一下。它的意思是“ENOMEM不是最明顯的選擇，尤其是對于 pid 創(chuàng)建失敗的情況下。但是，ENOMEM 是我們長期暴露給用戶空間的東西。因此，即使有更適合的錯誤代碼，我們也無法輕易更改它”

看到這兒，我想起了有不少人也稱 Linux 為屎山，可能這就是其中的一坨吧！最新的版本里也并沒有很好地解決這個問題。

結(jié)論

在 Linux 里創(chuàng)建進(jìn)程時，如果在 pid 不足的時候竟然返回的錯誤提示是“內(nèi)存不足”。這個不恰當(dāng)?shù)腻e誤提示導(dǎo)致很多同學(xué)都困惑不已。

通過今天的文章，以后你再遇到這種內(nèi)存不足錯誤的時候，你就要多留個心眼兒了，別被內(nèi)核被蒙騙了，先來看看自己的進(jìn)程（線程）數(shù)是不是過多了。

至于說發(fā)現(xiàn)了這個問題該如何解決嘛，可以通過修改內(nèi)核參數(shù)加大可用 pid 數(shù)量(/proc/sys/kernel/pid_max)。

但是我覺得最根本的方法還是要揪出來為啥系統(tǒng)中會出現(xiàn)這么多的進(jìn)程（線程），然后把它干掉。默認(rèn)情況下的兩三萬個進(jìn)程數(shù)對于絕大多數(shù)的服務(wù)器來說已經(jīng)是一個過于龐大的數(shù)字了，連這個數(shù)都超過了，一定是不合理的。