生產服務器配置：64核 128G內存， docker 內1400個容器，經常出現-bash: fork: retry: Resource temporarily unavailable ，連shell 也一樣，之前以為是ulimit 問題，找了很久沒解決，最后才找到 pid_max 引起的。。
系統中可創建的進程數實際值
linux內核通過進程標識值(process identification value)-PID來標示進程，PID是一個數，類型位pid_t, 實際上就是int類型
為了與老版本的Unix或者Linux兼容，PID的最大值默認設置位32768(short int 短整型的最大值)。
————————————————
版權聲明：本文為CSDN博主「CHENG Jian」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/gatieme/article/details/51058797
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。
A process cannot use more than NR_OPEN file descriptors.
一個進程不能使用超過NR_OPEN文件描述符。
1
2
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。以下設置需要注銷之后重新登錄才能生效：
chanon soft nofile 102400
chanon hard nofile 409600
1
2
設置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測試：
ulimit -n unlimited
1
bash: ulimit: open files: cannot modify limit: 不允許的操作
寫一個簡單的for循環得出：
for V in `seq 100000 10000000`;do ulimit -n $V；[[ $? != 0 ]]&&break;done
1
再執行ulimit -n ，可以看到1048576就是nofile的最大值了，但為什么是這個值？
1024∗1024=10485761024∗1024=1048576，當然這並沒有什么卵用。
再跟蹤一下我們就會發現這個值其實是由內核參數nr_open定義的：
cat /proc/sys/fs/nr_open
1
到此我們就要說起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打開數應該也夠用了吧。。
所有進程打開的文件描述符數不能超過/proc/sys/fs/file-max
單個進程打開的文件描述符數不能超過user limit中nofile的soft limit
nofile的soft limit不能超過其hard limit
nofile的hard limit不能超過/proc/sys/fs/nr_open
其他
如下內容轉載自
linux 單進程可創建最大線程數
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也變得瘋狂起來了？
————————————————
版權聲明：本文為CSDN博主「CHENG Jian」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/gatieme/article/details/51058797