LINUX中進程的最大理論數計算

LINUX中進程的最大理論數計算

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

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

• GDT的容量有多大呢？

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

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

所以系統中理論上最大的進程數是4090

系統中可創建的進程數實際值

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

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

• 查看

可以使用cat /proc/sys/kernel/pid_max來查看系統中可創建的進程數實際值

• 修改

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

我們在Linux還需要設置內核參數kernel.pid_max，這個參數我默認安裝都是32768,

所以即使使用root帳戶，卻不設置這個內核參數，整個系統最多可以創建的進程數就是32768，所以我們需要進行如下設置:

最大線程數

linux 系統中單個進程的最大線程數有其最大的限制 PTHREAD_THREADS_MAX

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

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

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

試驗顯示，在我們的系統(Ubuntu-14.04-LTS-64bit)中linuxthreads 上最多可以創建 381 個線程，之后就會返回 EAGAIN

LINUX中單個進程理論上可以創建的最大線程數

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

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

為了突破內存的限制，可以有兩種方法

• 用ulimit -s 1024減小默認的棧大小
• 調用pthread_create的時候用pthread_attr_getstacksize設置一個較小的棧大小

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

最大打開文件數

file-max系統最大打開文件描述符數

/proc/sys/fs/file-max中指定了系統范圍內所有進程可打開的文件句柄的數量限制(系統級別, 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”這樣的錯誤消息時, 就應該曾加這個值了.

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

查看實際值

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

設置

• 臨時性

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

• 永久性：在/etc/sysctl.conf中設置

fs.file-max = 1000000

nr_open是單個進程可分配的最大文件數

內核支持的最大file handle數量，即一個進程最多使用的file handle數

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

nofile進程最大打開文件描述符數

查看實際值

ulimit -n

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

設置

• 臨時性

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

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

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

• 永久性

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

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

設置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之間的關系

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

“maximum number of open files”，

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

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

可是當你實際給nofile設置成這個值，等你重啟就會發現無法登錄系統了。

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

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

寫一個簡單的for循環得出：

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

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

再跟蹤一下我們就會發現這個值其實是由內核參數nr_open定義的：

到此我們就要說起nr_open，與file-max了，網上在說到設置最大文件數時偶爾有些帖子也說到要修改file-max，字面上看file-max確實像是對應最大文件數，而在linux內核文檔中它們兩的解釋是：

• 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

執行：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語言中這兩個概念的區別，

據他們的討論file-handle應該是一個高層的對象，使用fopen，fread等函數來調用，而FD是底層的一個對象，可以通過open，read等函數來調用。

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

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

其他

2.4內核與2.6內核的主要區別

在2.4內核的典型系統上（AS3/RH9），線程是用輕量進程實現的，每個線程要占用一個進程ID，在服務器程序上，如果遇到高點擊率訪問，會造成進程表溢出，系統為了維護溢出的進程表，會有間歇的暫停服務現象，而2.6內核就不會發生由于大量線程的創建和銷毀導致進程表溢出的問題

線程結束必須釋放線程堆棧

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

不要編需要鎖的線程應用

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

單進程服務器最大并發線程數與內存

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

附注1

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

附注2

測試單進程創建線程上限C源碼（test.c）