[[400910]]

 前言

在我們寫程序的時(shí)候往往都沒有注意到一些系統(tǒng)資源的臨界值，然而這些臨界值在有的時(shí)候會(huì)把我們害的很慘，比如一個(gè)忘掉關(guān)閉的文件描述符，比如malloc竟然會(huì)返回錯(cuò)誤，又或者是爆棧，我們?cè)撊绾谓鉀Q或者說預(yù)防這些問題呢？

以下實(shí)驗(yàn)僅在本機(jī)的系統(tǒng)環(huán)境下生效：

用戶層面資源限制

ulimit 命令可以查看用戶層面的系統(tǒng)資源限制。這是在 /etc/security/limits.conf 的描述:

-----------------------------------------------------

該文件為通過PAM登錄的用戶設(shè)置資源限制。

它不會(huì)影響系統(tǒng)服務(wù)的資源限制。

還要注意 /etc/security/limits.d 目錄中的配置文件，以字母順序閱讀的內(nèi)容，請(qǐng)覆蓋此設(shè)置域相同或更具體的情況下使用文件。

例如，這意味著在此處設(shè)置通配符域的限制可以使用配置文件中的通配符設(shè)置覆蓋子目錄，但此處的用戶特定設(shè)置只能被覆蓋在子目錄中具有特定于用戶的設(shè)置。

-----------------------------------------------------

所以 ulimit 的確是觀察用戶層面的資源限制。

我們可以通過 ulimit -a 查看我們所有的資源上限：

 

只說其中我們比較關(guān)注的那些：

-s 棧大小:8MB

-u 進(jìn)程上限:30000多

-n 文件描述符上限:1024

同時(shí)你可以用ulimit -Ha或ulimit -Sa查看硬限制和軟限制，硬限制是指對(duì)資源節(jié)點(diǎn)和數(shù)據(jù)塊的絕對(duì)限制，由 root 用戶設(shè)置硬限制。雖然其他用戶可以降低硬限制，但只有 root 用戶可以增加硬限制。至于軟限制，網(wǎng)上資料也沒有說什么，大概就是非root用戶不能超過軟限制，但是非root用戶可以做的是將其軟限制增加到其硬限制。

我們的服務(wù)器程序可能有打開超過1024個(gè)文件描述符，有沒有辦法修改這些資源的上限呢？

E.g. ulimit -n 1024可以修改系統(tǒng)對(duì)文件描述符的限制，不過是臨時(shí)當(dāng)前的shell生效的,如果你使用which ulimit你會(huì)發(fā)現(xiàn)ulimit是一個(gè)shell built-in command的腳本。

我們應(yīng)該修改 /etc/security/limits.conf 去讓我們的修改永久生效。(需要重新啟動(dòng),可能有直接加載配置的方法，暫時(shí)不知道)

實(shí)驗(yàn)1. 修改文件描述符上限

在/etc/security/limits.conf中添加以下片段：

重啟后，然后查看一下資源是否真的被修改了:

說明修改成功。那么現(xiàn)在我們測(cè)試下我們的程序能否打開這么多個(gè)文件描述符？做個(gè)小測(cè)試，下面就是打開10240個(gè)臨時(shí)文件，這里我們期待錯(cuò)誤 EFILE：

接著我們看一下結(jié)果：

在修改之前是ulimit的默認(rèn)值是1024,然后測(cè)試出的最大打開文件描述符的數(shù)量是1001,現(xiàn)在是修改為10240后可以打開10217個(gè)文件描述符，實(shí)驗(yàn)成功。然后我們能打開的總數(shù)為什么不是剛好10240呢？這個(gè)問題是因?yàn)槌绦蜃陨泶蜷_了一些文件或是加載了一些動(dòng)態(tài)庫,stdin/stdout/stderr,以及 /etc/ld.so.cache，/usr/lib/libm.so.6，/usr/lib/libstdc++.so.6...

實(shí)驗(yàn)2. 修改?？臻g上限

同樣還是在/etc/security/limits.conf添加這樣兩句：

然后在c程序中測(cè)試棧幀的上限：

程序正常。將棧調(diào)到臨界值：

程序發(fā)生段錯(cuò)誤。

但這里也只能保守的說：調(diào)整以后的一個(gè)進(jìn)程的?？臻g大概在 8192000B 這附近。

系統(tǒng)層面資源限制

單個(gè)進(jìn)程打開文件句柄數(shù)上限 最大文件描述符數(shù) 10億。

 

系統(tǒng)分配的pid上限是400多萬。

file-max是在內(nèi)核級(jí)別強(qiáng)制執(zhí)行的最大文件描述符（FD），上限600萬。

已分配的文件文件描述符數(shù)，已分配但未使用的文件描述符數(shù)以及最大文件描述符數(shù)(不可調(diào))。

系統(tǒng)全局的總線程數(shù)限制為6萬。

單個(gè)程序所能使用內(nèi)存映射空間的數(shù)量為6萬。

 

可以創(chuàng)建的線程的總數(shù)和這些有關(guān)：

一個(gè)進(jìn)程的資源限制

redis中文件描述符上限的調(diào)整

你覺得資源限制和你沒有關(guān)系？在你打開 redis-server 的時(shí)候，難道就沒有注意到這樣的一段：

Increased maximum number of open files to 10032 (it was originally set to 1024).

其含義就是將文件描述符從默認(rèn)的上限調(diào)整到10032，為了適應(yīng)更多的網(wǎng)絡(luò)連接。

其源碼中也不過是調(diào)用了api:

setrlimit(RLIMIT_NOFILE,&limit)

去進(jìn)行了資源上限的臨時(shí)調(diào)整，此處不細(xì)講。

prlimit

最后介紹另外一個(gè)類似ulimit的命令prlimit：

結(jié)語

linux的資源限制不能說很奇妙吧，但確實(shí)值得做linux服務(wù)端編程的程序員們需要注意，同時(shí)我們可以通過在 /etc/security/limits.conf 去修改資源的上限。忽然想到上次問學(xué)長：為什么linux下需要對(duì)這些資源進(jìn)行限制？都調(diào)整為ulimited不是很好么？

可以說我們的linux機(jī)器之所以限制這些資源的上限，是希望我們能夠充分利用它，把它的性能發(fā)揮到極致，而不是讓CPU或者文件等資源在那里閑置著，浪費(fèi)計(jì)算機(jī)的生命。