-bash: fork: retry: Resource temporarily unavailable

生产服务器配置：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