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

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

• 每個進程都要在全局段描述表GDT中占據(jù)兩個表項

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

• GDT的容量有多大呢？

段寄存器中用作GDT表下標的位段寬度是13位，所以GDT中可以有213=8192213=8192個描述項。

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

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

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

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

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

• 查看

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

• 修改

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

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

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

最大線程數(shù)

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

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

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

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

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

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

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

那為什么 linuxthreads 上還要少一個線程呢？這可太對了，因為 linuxthreads 還需要一個管理線程

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

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

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

最大打開文件數(shù)

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

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

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

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

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

查看實際值

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

設(shè)置

• 臨時性

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

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

fs.file-max = 1000000

nr_open是單個進程可分配的最大文件數(shù)

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

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

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

查看實際值

ulimit -n

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

設(shè)置

• 臨時性

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

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

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

• 永久性

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

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

設(shè)置nofile的hard limit還有一點要注意的就是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)系

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

“maximum number of open files”，

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

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

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

由此可見，nofile是有一個上限的，同時用ulimit測試：

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

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

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

1024?1024=10485761024?1024=1048576，當然這并沒有什么卵用。

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

到此我們就要說起nr_open，與file-max了，網(wǎng)上在說到設(shè)置最大文件數(shù)時偶爾有些帖子也說到要修改file-max，字面上看file-max確實像是對應(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中是一個類似file discrptor的東東，但是我們討論的是linux，再google一下，我們可以精確到c語言中這兩個概念的區(qū)別，

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

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

1. 所有進程打開的文件描述符數(shù)不能超過/proc/sys/fs/file-max
2. 單個進程打開的文件描述符數(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），線程是用輕量進程實現(xiàn)的，每個線程要占用一個進程ID，在服務(wù)器程序上，如果遇到高點擊率訪問，會造成進程表溢出，系統(tǒng)為了維護溢出的進程表，會有間歇的暫停服務(wù)現(xiàn)象，而2.6內(nèi)核就不會發(fā)生由于大量線程的創(chuàng)建和銷毀導(dǎo)致進程表溢出的問題

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

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

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

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

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

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

附注1

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

附注2

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