df卡死和fork:cannot allocate memory报错

早上到了公司，发现docker资源池的某一台主机根文件系统写满。

检查后发现该主机/data目录未挂载文件系统，直接放在了根目录下。于是联系业务方将应用迁移，联系主机工程师为/data挂载80G的存储空间。

接着顺便检查了其它资源池主机的磁盘分区上可使用的磁盘空间。使用df -h命令查询，结果直接hang死。

去其它主机执行df命令，同样全部hang死。

随后主机上Docker容器内跑的业务开始报错。

尝试检查/var/log/message系统日志，发现全部被业务的报错日志充斥，可读性很差。

最后服务器开始开始出现故障，ssh连接不上去。即使偶尔有人登录成功，执行任何命令都会提示：

-bash: fork: Cannot allocate memory 

主机工程师只能前往机房将主机重启，结果重启后发现这台主机居然没有在/etc/fstab中配置/data目录自动挂载，重启后/data目录丢失，应用再次开始大规模报错。于是顺便检查了资源池的其它几台主机，发现有些主机/data目录未挂载、有些主机挂载后未配置开机自动挂载、有些主机/data目录挂载了但是自动挂载配的另一个文件系统、还有些主机密码不知道被谁改了只能重新刷密码，总之是问题多多。

首先联系业务方将日志输入级别改了，把输出到/var/log/message的日志全部停下。

然后检查日志；

查看内存发现主机内存仍然很充裕，不可能是内存耗尽引起的故障；

查看进程表，发现主机上有大量同PID、同PPID进程，而且还在疯狂增加，很快增加到十几万之多，很快意识到这些都是疯狂增加的线程，因为进程数和线程数疯狂增加，达到pid_max。经过验证确实pid_max用尽会导致fork问题。

于是查询出错时的操作记录，发现中午有人发布的新版本镜像，即问题所在。

虽然修改pid_max可以解决这个问题，但这只是治标不治本的方法。其实正常情况下pid_max完全够用，应该合理规划pid_max和thread_max的值.

df卡死其实是另一个故障了：使用strace df -h追踪出错原因，发现每次都在/proc/sys/fs/binfmt_misc处hang死。在/etc/mtab中可以查询到这个目录，但主机上实际不存在这个目录。

进入/proc/sys/fs执行ls命令，同样出现hang死。

于是重新配置好所有开机自动挂载信息，将所有出现故障的主机全部重启，该问题暂时解决。

最后提出的处理方法：