你真知道“Too many open files”?

作者：邢森 2017-01-09 16:35:25

ulimit這個(gè)命令其實(shí)是系統(tǒng)的內(nèi)部命令(不信你打which ulimit)它也是調(diào)用setrlimit完成的設(shè)置。二者的區(qū)別是pam_limit是自動(dòng)加載的(屬于linux的“認(rèn)證模塊”)，ulimit你必須動(dòng)手輸入命令。

江湖上的人都碰到過Too many open files的錯(cuò)誤(無論你是多線程，網(wǎng)絡(luò)socket，還是別的什么幺蛾子，這個(gè)錯(cuò)誤很常見)。筆者一個(gè)朋友剛好也碰到過，經(jīng)過一番搜索最終解決了問題。但是始終沒有搞清楚——“到底問題出在哪里?”。我當(dāng)然也講不清楚(否則就不會(huì)有這篇文章咯)網(wǎng)上也找不到相關(guān)資料。作為一個(gè)有良知的自媒體公眾賬號(hào)，我決定要把替大家去深究一下這個(gè)問題。(花了兩個(gè)晚上~~，記得打賞我)

網(wǎng)上流傳的三種做法：

修改ulimit命令修改，這種修改只能在當(dāng)前會(huì)話有效或者/etc/security/limits.conf設(shè)置hard soft nofile，可以一直有效
sysctl修改fs.file-max
修改/proc/sys/fs/nr_open(可選)

還有一種傳說這是有優(yōu)先級(jí)的——limit.conf < fs.file-max < nr_open

然而這都是扯淡，純粹的臆想。有良知的自媒體公眾賬號(hào)是講道理的，正所謂——沒代碼你說個(gè)屁啊!!!;所以我就順著Linux Kernel的代碼挖了下去。

Linux/Unix一個(gè)著名的哲學(xué)就是——“萬物皆文件”，無論是一個(gè)線程、socket、還是真正的文件都會(huì)被當(dāng)做“文件”。Too may open files通常意味著“文件描述符”不足，它一般會(huì)發(fā)生在“創(chuàng)建線程”、“創(chuàng)建socket”、“打開文件”這種場(chǎng)景下。我選“創(chuàng)建socket”作為出發(fā)點(diǎn)

文件描述符的限制?不對(duì)!!

調(diào)用socket函數(shù)的時(shí)候內(nèi)核會(huì)分兩步操作——填充數(shù)據(jù)結(jié)構(gòu)，分配fd。我們重點(diǎn)看socket_map_fd

關(guān)鍵的地方來了，get_unused_fd_flags會(huì)嘗試分配一個(gè)fd，但是這個(gè)僅僅是fd——是一個(gè)數(shù)字而已;就是我們常說的——文件描述符。僅僅有一個(gè)數(shù)字并不代表什么，它相當(dāng)于一個(gè)占位符，系統(tǒng)并沒有實(shí)際的分配資源。socket_alloc_file才是真正的建立文件結(jié)構(gòu)(內(nèi)核的數(shù)據(jù)結(jié)構(gòu)：struct file)。打開get_unsed_fd_flags摸下去：

同志們，重點(diǎn)又來了。rlimit(RLIMIT_NOFILE)這個(gè)函數(shù)得到的是soft nofile，我們繼續(xù)看__alloc_fd

fd備用有三部分組成，進(jìn)程當(dāng)前預(yù)分配的(fd位圖中設(shè)置了標(biāo)記，fdt->next_fd);進(jìn)程當(dāng)前可用的(fd位圖中沒有設(shè)置標(biāo)記，fdt->max_fds);進(jìn)程擴(kuò)展的(fd位圖中都不存在，需要執(zhí)行expand_files擴(kuò)展fd位圖)所以__alloc_fd函數(shù)分為了三步嘗試分配fd。

嘗試“預(yù)分配”的fd(直接分配)
嘗試分配“可用的”的fd(需要填充位圖)
嘗試擴(kuò)展fd位圖大小

如果fd超過soft nofile，這個(gè)函數(shù)會(huì)直接返回“錯(cuò)誤”。所以soft nofile是fd大小限制的***道關(guān)卡，hard nofile全程沒用。soft nofile的準(zhǔn)確而含義是——當(dāng)前可以使用多少fd。

當(dāng)前是跟“進(jìn)程”有關(guān)系的，詳細(xì)內(nèi)容請(qǐng)看***一部分。我們繼續(xù)看“擴(kuò)充”fd：

fs.nr_open是文件描述符的***一道關(guān)卡，當(dāng)我們嘗試擴(kuò)充文件描述符的時(shí)候只要你不大于它系統(tǒng)就允許你擴(kuò)充，它的***值是2147483584。

結(jié)論：

soft nofile、fs.nr_open是用來控制文件描述符數(shù)量的
soft nofile其實(shí)是linux的pam_limit模塊設(shè)置的如果你不啟用這個(gè)模塊，你只能通過ulimit命令調(diào)整。如果不調(diào)整它的值是4096(可以看***的代碼圖)
nr_open表示文件描述符***數(shù)量。它的***值是2147483584(64位機(jī)器上2^31-64)。這也是是soft nofile、fs.nr_open可以設(shè)置的***值。

文件結(jié)構(gòu)體

文件描述符在內(nèi)核中其實(shí)是一個(gè)數(shù)字，它代表的是一個(gè)“索引”而索引的內(nèi)容是“文件結(jié)構(gòu)體”(內(nèi)核數(shù)據(jù)結(jié)構(gòu) struct file)。內(nèi)核分配資源的時(shí)候把“索引”和“內(nèi)容”當(dāng)做兩種資源來分配。先申請(qǐng)“索引”后申請(qǐng)“內(nèi)容”。跳回sock_map_fd看第二步——分配文件結(jié)構(gòu)，它調(diào)用了sock_alloc_file函數(shù)。

順著這個(gè)函數(shù)走下去你會(huì)發(fā)現(xiàn)——file-max(為了節(jié)省版面，完整的代碼圖我附在后面)

file-max是指struct file的上限。你可以把soft nofile、fs.nr_open設(shè)置成天文數(shù)字，但是不設(shè)置file-max就意味著沒法分配struct file，文件描述符就沒用了，依舊資源分配不成功。(像12306，你搶到票還不行還得“排隊(duì)”。搶到的僅僅是一個(gè)占位符，到***可能“沒票了”。對(duì)，我沒買到車票，等大家眾籌機(jī)票了。)

總結(jié)：

fs.file-max是用來控制文件結(jié)構(gòu)體數(shù)量的

等等，還沒結(jié)束

上面已經(jīng)扒出了三個(gè)參數(shù)的真實(shí)意義，但是作為一個(gè)——有良知的自媒體公眾號(hào)必須把道理講清楚。所以我就挖出了soft nofile的前生今世。

PAM(Pluggable Authentication Modules)是Linux的認(rèn)證框架，在系統(tǒng)啟動(dòng)成功后無論是后臺(tái)服務(wù)進(jìn)程還是bash都會(huì)通過setup_limits加載/etc/security/limit.conf文件然后調(diào)用setrlimit重新設(shè)置進(jìn)程的rlimt——其中就包括了soft nofile。(pam_limit不在內(nèi)核代碼中它有自己獨(dú)立的代碼倉庫，為了做有良知的自媒體我是不是特別拼?)