LINUX中進(jìn)程的最大理論數(shù)計(jì)算

LINUX中進(jìn)程的最大理論數(shù)計(jì)算

• 每個(gè)進(jìn)程都要在全局段描述表GDT中占據(jù)兩個(gè)表項(xiàng)

每個(gè)進(jìn)程的局部段描述表LDT都作為一個(gè)獨(dú)立的段而存在，在全局段描述表GDT中要有一個(gè)表項(xiàng)指向這個(gè)段的起始地址，并說明該段的長(zhǎng)度以及其他一些 參數(shù)。除上之外，每個(gè)進(jìn)程還有一個(gè)TSS結(jié)構(gòu)(任務(wù)狀態(tài)段)也是一樣。所以，每個(gè)進(jìn)程都要在全局段描述表GDT中占據(jù)兩個(gè)表項(xiàng)。

• GDT的容量有多大呢？

段寄存器中用作GDT表下標(biāo)的位段寬度是13位，所以GDT中可以有213=8192213=8192個(gè)描述項(xiàng)。

除一些系統(tǒng)的開銷(例如GDT中的第2項(xiàng)和第3項(xiàng)分別用于內(nèi)核 的代碼段和數(shù)據(jù)段，第4項(xiàng)和第5項(xiàng)永遠(yuǎn)用于當(dāng)前進(jìn)程的代碼段和數(shù)據(jù)段，第1項(xiàng)永遠(yuǎn)是0，等等)以外，尚有8180個(gè)表項(xiàng)可供使用，所以理論上系統(tǒng)中最大的 進(jìn)程數(shù)量是8180/2=40908180/2=4090。

所以系統(tǒng)中理論上最大的進(jìn)程數(shù)是4090

系統(tǒng)中可創(chuàng)建的進(jìn)程數(shù)實(shí)際值

linux內(nèi)核通過進(jìn)程標(biāo)識(shí)值(process identification value)-PID來標(biāo)示進(jìn)程，PID是一個(gè)數(shù)，類型位pid_t, 實(shí)際上就是int類型

為了與老版本的Unix或者Linux兼容，PID的最大值默認(rèn)設(shè)置位32768(short int 短整型的最大值)。

• 查看

可以使用cat /proc/sys/kernel/pid_max來查看系統(tǒng)中可創(chuàng)建的進(jìn)程數(shù)實(shí)際值

• 修改

設(shè)置完以后，雖然我們?cè)O(shè)置戶創(chuàng)建進(jìn)程數(shù)的硬限制和軟限制都是65535，但是我們還不能使用創(chuàng)建65535個(gè)進(jìn)程

我們?cè)贚inux還需要設(shè)置內(nèi)核參數(shù)kernel.pid_max，這個(gè)參數(shù)我默認(rèn)安裝都是32768,

所以即使使用root帳戶，卻不設(shè)置這個(gè)內(nèi)核參數(shù)，整個(gè)系統(tǒng)最多可以創(chuàng)建的進(jìn)程數(shù)就是32768，所以我們需要進(jìn)行如下設(shè)置:

最大線程數(shù)

linux 系統(tǒng)中單個(gè)進(jìn)程的最大線程數(shù)有其最大的限制 PTHREAD_THREADS_MAX

這個(gè)限制可以在/usr/include/bits/local_lim.h中查看 對(duì) linuxthreads 這個(gè)值一般是 1024，對(duì)于 nptl 則沒有硬性的限制，僅僅受限于系統(tǒng)的資源

這個(gè)系統(tǒng)的資源主要就是線程的 stack 所占用的內(nèi)存，用 ulimit -s 可以查看默認(rèn)的線程棧大小，一般情況下，這個(gè)值是8M=8192KB

可以寫一段簡(jiǎn)單的代碼驗(yàn)證最多可以創(chuàng)建多少個(gè)線程

試驗(yàn)顯示，在我們的系統(tǒng)(Ubuntu-14.04-LTS-64bit)中l(wèi)inuxthreads 上最多可以創(chuàng)建 381 個(gè)線程，之后就會(huì)返回 EAGAIN

LINUX中單個(gè)進(jìn)程理論上可以創(chuàng)建的最大線程數(shù)

而32位系統(tǒng)中，可以穿件381個(gè)線程，這個(gè)值和理論完全相符，因?yàn)?32 位 linux 下的進(jìn)程用戶空間是 3G 的大小，也就是 3072M，用3072M/8M=3843072M/8M=384，但是實(shí)際上代碼段和數(shù)據(jù)段等還要占用一些空間，這個(gè)值應(yīng)該向下取整到 383，再減去主線程，得到 382。

那為什么 linuxthreads 上還要少一個(gè)線程呢？這可太對(duì)了，因?yàn)?linuxthreads 還需要一個(gè)管理線程

為了突破內(nèi)存的限制，可以有兩種方法

• 用ulimit -s 1024減小默認(rèn)的棧大小
• 調(diào)用pthread_create的時(shí)候用pthread_attr_getstacksize設(shè)置一個(gè)較小的棧大小

要注意的是，即使這樣的也無法突破1024 個(gè)線程的硬限制，除非重新編譯 C 庫

最大打開文件數(shù)

file-max系統(tǒng)最大打開文件描述符數(shù)

/proc/sys/fs/file-max中指定了系統(tǒng)范圍內(nèi)所有進(jìn)程可打開的文件句柄的數(shù)量限制(系統(tǒng)級(jí)別, kernel-level).

The value in file-max denotes the maximum number of file handles that the Linux kernel will allocate）.

當(dāng)收到”Too many open files in system”這樣的錯(cuò)誤消息時(shí), 就應(yīng)該曾加這個(gè)值了.

對(duì)于2.2的內(nèi)核, 還需要考慮inode-max, 一般inode-max設(shè)置為file-max的4倍. 對(duì)于2.4及以后的內(nèi)核, 沒有inode-max這個(gè)文件了.

查看實(shí)際值

可以使用cat /proc/sys/fs/file-max來查看當(dāng)前系統(tǒng)中單進(jìn)程可打開的文件描述符數(shù)目 186405

設(shè)置

• 臨時(shí)性

echo 1000000 > /proc/sys/fs/file-max

• 永久性：在/etc/sysctl.conf中設(shè)置

fs.file-max = 1000000

nr_open是單個(gè)進(jìn)程可分配的最大文件數(shù)

內(nèi)核支持的最大file handle數(shù)量，即一個(gè)進(jìn)程最多使用的file handle數(shù)

the maximum number of files that can be opened by process。

nofile進(jìn)程最大打開文件描述符數(shù)

查看實(shí)際值

ulimit -n

當(dāng)然默認(rèn)查看的是軟資源限制值soft limit，如果想要查看系統(tǒng)硬件所能支持的單進(jìn)程最大打開文件描述符號(hào)的數(shù)目，可以使用ulimit -Hn

設(shè)置

• 臨時(shí)性

通過ulimit -Sn設(shè)置最大打開文件描述符數(shù)的soft limit，注意soft limit不能大于hard limit（ulimit -Hn可查看hard limit）

另外ulimit -n默認(rèn)查看的是soft limit，但是ulimit -n 1800000則是同時(shí)設(shè)置soft limit和hard limit。

對(duì)于非root用戶只能設(shè)置比原來小的hard limit。

• 永久性

上面的方法只是臨時(shí)性的，注銷重新登錄就失效了，而且不能增大hard limit，只能在hard limit范圍內(nèi)修改soft limit。

若要使修改永久有效，則需要在/etc/security/limits.conf中進(jìn)行設(shè)置（需要root權(quán)限），可添加如下兩行，表示用戶chanon最大打開文件描述符數(shù)的soft limit為1800000，hard limit為2000000。以下設(shè)置需要注銷之后重新登錄才能生效：

設(shè)置nofile的hard limit還有一點(diǎn)要注意的就是hard limit不能大于/proc/sys/fs/nr_open，假如hard limit大于nr_open，注銷后無法正常登錄。

可以修改nr_open的值：

echo 2000000 > /proc/sys/fs/nr_open

file-max, nr_open, onfile之間的關(guān)系

針對(duì)用戶打開最大文件數(shù)的限制， 在limits.conf對(duì)應(yīng)的nofile，不管是man手冊(cè)還是文件中說明都只是一句話

“maximum number of open files”，

它其實(shí)對(duì)應(yīng)是單個(gè)進(jìn)程能打開的最大文件數(shù)，通常為了省事，我們想取消它的限制

根據(jù)man手冊(cè)中，“values -1, unlimited or infinity indicating no limit”，-1、unlimited、infinity都是表明不做限制

可是當(dāng)你實(shí)際給nofile設(shè)置成這個(gè)值，等你重啟就會(huì)發(fā)現(xiàn)無法登錄系統(tǒng)了。

由此可見，nofile是有一個(gè)上限的，同時(shí)用ulimit測(cè)試：

bash: ulimit: open files: cannot modify limit: 不允許的操作

寫一個(gè)簡(jiǎn)單的for循環(huán)得出：

再執(zhí)行ulimit -n ，可以看到1048576就是nofile的最大值了，但為什么是這個(gè)值？

1024?1024=10485761024?1024=1048576，當(dāng)然這并沒有什么卵用。

再跟蹤一下我們就會(huì)發(fā)現(xiàn)這個(gè)值其實(shí)是由內(nèi)核參數(shù)nr_open定義的：

到此我們就要說起nr_open，與file-max了，網(wǎng)上在說到設(shè)置最大文件數(shù)時(shí)偶爾有些帖子也說到要修改file-max，字面上看file-max確實(shí)像是對(duì)應(yīng)最大文件數(shù)，而在linux內(nèi)核文檔中它們兩的解釋是：

• file-max：The value in file-max denotes the maximum number of file- handles that the Linux kernel will allocate. When you get lots of error messages about running out of file handles, you might want to increase this limit

執(zhí)行：grep -r MemTotal /proc/meminfo | awk ‘{printf(“%d”,$2/10)}’，可以看到與file-max是相近的；

• nr_open:
  This denotes the maximum number of file-handles a process can allocate. Default value is 1024*1024 (1048576) which should be enough for most machines. Actual limit depends on RLIMIT_NOFILE resource limit.

file-handles（即文件句柄），然后相比而言在UNIX/LINUX中我們接觸更多是file discriptor（FD，即文件描述符)，似乎file-handle在windows中是一個(gè)類似file discrptor的東東，但是我們討論的是linux，再google一下，我們可以精確到c語言中這兩個(gè)概念的區(qū)別，

據(jù)他們的討論file-handle應(yīng)該是一個(gè)高層的對(duì)象，使用fopen，fread等函數(shù)來調(diào)用，而FD是底層的一個(gè)對(duì)象，可以通過open，read等函數(shù)來調(diào)用。

到此，我們應(yīng)該可以下一個(gè)大致的結(jié)論了，file-max是內(nèi)核可分配的最大文件數(shù)，nr_open是單個(gè)進(jìn)程可分配的最大文件數(shù)，所以在我們使用ulimit或limits.conf來設(shè)置時(shí)，如果要超過默認(rèn)的1048576值時(shí)需要先增大nr_open值（sysctl -w fs.nr_open=100000000或者直接寫入sysctl.conf文件）。當(dāng)然百萬級(jí)別的單進(jìn)程最大file-handle打開數(shù)應(yīng)該也夠用了吧。。

1. 所有進(jìn)程打開的文件描述符數(shù)不能超過/proc/sys/fs/file-max
2. 單個(gè)進(jìn)程打開的文件描述符數(shù)不能超過user limit中nofile的soft limit
3. nofile的soft limit不能超過其hard limit
4. nofile的hard limit不能超過/proc/sys/fs/nr_open

其他

2.4內(nèi)核與2.6內(nèi)核的主要區(qū)別

在2.4內(nèi)核的典型系統(tǒng)上（AS3/RH9），線程是用輕量進(jìn)程實(shí)現(xiàn)的，每個(gè)線程要占用一個(gè)進(jìn)程ID，在服務(wù)器程序上，如果遇到高點(diǎn)擊率訪問，會(huì)造成進(jìn)程表溢出，系統(tǒng)為了維護(hù)溢出的進(jìn)程表，會(huì)有間歇的暫停服務(wù)現(xiàn)象，而2.6內(nèi)核就不會(huì)發(fā)生由于大量線程的創(chuàng)建和銷毀導(dǎo)致進(jìn)程表溢出的問題

線程結(jié)束必須釋放線程堆棧

就是說，線程函數(shù)必須調(diào)用pthread_exit()結(jié)束，否則直到主進(jìn)程函數(shù)退出才釋放，特別是2.6內(nèi)核環(huán)境，線程創(chuàng)建速度飛快，一不小心立刻內(nèi)存被吃光，這一點(diǎn)反倒是2.4內(nèi)核環(huán)境好，因?yàn)?.4內(nèi)核創(chuàng)建的是進(jìn)程，而且線程創(chuàng)建速度比2.6內(nèi)核慢幾個(gè)數(shù)量級(jí)。特別提醒，在64位CPU，2.6內(nèi)核創(chuàng)建線程的速度更加瘋狂，要是太快的話，加上usleep ()暫停一點(diǎn)點(diǎn)時(shí)間比較好

不要編需要鎖的線程應(yīng)用

只有那些不需要互斥量的程序才能最大限度的利用線程編程帶來的好處，否則只會(huì)更慢，2.6內(nèi)核是搶占式內(nèi)核，線程間共享沖突發(fā)生的幾率遠(yuǎn)比2.4內(nèi)核環(huán)境高，尤其要注意線程安全，否則就算是單CPU也會(huì)發(fā)生莫名其妙的內(nèi)存不同步（CPU的高速緩存和主存內(nèi)容不一致），Intel的新CPU為了性能使用NUMA架構(gòu)，在線程編程中一定要注意揚(yáng)長(zhǎng)避短。

單進(jìn)程服務(wù)器最大并發(fā)線程數(shù)與內(nèi)存

很有趣，在默認(rèn)的ulimit參數(shù)下，不修改內(nèi)核頭文件 AS3 512M內(nèi)存最多1000并發(fā)持續(xù)連接 CentOS4.3 512M內(nèi)存最多300并發(fā)持續(xù)連接 似乎是CentOS不如AS3，這里主要原因是ulimit的配置造成，兩個(gè)系統(tǒng)默認(rèn)的配置差距很大，要想單進(jìn)程維持更多線程接收并發(fā)連接，就要盡量縮小 ulimit -s的參數(shù)，插更多的內(nèi)存條，單進(jìn)程服務(wù)器上2000并發(fā)一點(diǎn)都不難，POSIX默認(rèn)的限制是每進(jìn)程64線程，但NTPL并非純正POSIX，不必理會(huì)這個(gè)限制，2.6內(nèi)核下真正的限制是內(nèi)存條的插槽數(shù)目（也許還有買內(nèi)存的錢數(shù)） 最近幾天的編程中，注意到在32位x86平臺(tái)上2.6內(nèi)核單進(jìn)程創(chuàng)建最大線程數(shù)＝VIRT上限／stack，與總內(nèi)存數(shù)關(guān)系不大，32位x86系統(tǒng)默認(rèn)的VIRT上限是3G（內(nèi)存分配的3G+1G方式），默認(rèn) stack大小是10240K，因此單進(jìn)程創(chuàng)建線程默認(rèn)上限也就300（3072M / 10240K），用ulimit -s 修改stack到1024K則使上限升到大約3050。我手頭沒有64位系統(tǒng)，不知道2.6內(nèi)核在64位上單進(jìn)程創(chuàng)建線程上限（實(shí)際上是本人懶得在同事的機(jī)器上裝fc4_x86_64）。前些天買了一套廉價(jià)的64位x86系統(tǒng)(64位賽楊+雜牌915主板),安裝了CentOS4.3的x86_64版本,跑了一遍下面的小程序,得到的結(jié)果是:在ulimit -s 4096的情況下,單進(jìn)程最大線程數(shù)在16000多一點(diǎn),用top看 VIRT 的上限是64G,也就是36位, cat /proc/cpuinfo的結(jié)果是:address sizes : 36 bits physical, 48 bits virtual, 和我想象的標(biāo)準(zhǔn)64位系統(tǒng)不同, 我一直以為64位系統(tǒng)的內(nèi)存空間也是64位的

附注1

單位里某BSD FANS用AMD64筆記本跑小程序測(cè)試線程創(chuàng)建速度（線程創(chuàng)建后立即phread_detach()然后緊跟著pthread_exit()，共計(jì) 100萬個(gè)線程），同樣源碼OpenBSD竟然比FreeBSD快了3倍，什么時(shí)候OpenBSD也變得瘋狂起來了？

附注2

測(cè)試單進(jìn)程創(chuàng)建線程上限C源碼（test.c）