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

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

每個(gè)進(jìn)程的局部段描述表LDT都作為一個(gè)獨(dú)立的段而存在，在全局段描述表GDT中要有一個(gè)表項(xiàng)指向這個(gè)段的起始地址，并說(shuō)明該段的長(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)核通過(guò)進(jìn)程標(biāo)識(shí)值(process identification value)-PID來(lái)標(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來(lái)查看系統(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è)較小的棧大小

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

最大打開文件數(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來(lái)查看當(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í)性

通過(guò)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è)置比原來(lái)小的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，注銷后無(wú)法正常登錄。

可以修改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è)還是文件中說(shuō)明都只是一句話

“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)無(wú)法登錄系統(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定義的：

到此我們就要說(shuō)起nr_open，與file-max了，網(wǎng)上在說(shuō)到設(shè)置最大文件數(shù)時(shí)偶爾有些帖子也說(shuō)到要修改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語(yǔ)言中這兩個(gè)概念的區(qū)別，

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

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

1. 所有進(jìn)程打開的文件描述符數(shù)不能超過(guò)/proc/sys/fs/file-max
2. 單個(gè)進(jìn)程打開的文件描述符數(shù)不能超過(guò)user limit中nofile的soft limit
3. nofile的soft limit不能超過(guò)其hard limit
4. nofile的hard limit不能超過(guò)/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)擊率訪問(wè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)程表溢出的問(wèn)題

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

就是說(shuō)，線程函數(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)用

只有那些不需要互斥量的程序才能最大限度的利用線程編程帶來(lái)的好處，否則只會(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萬(wàn)個(gè)線程），同樣源碼OpenBSD竟然比FreeBSD快了3倍，什么時(shí)候OpenBSD也變得瘋狂起來(lái)了？

附注2

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