早上到了公司，发现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死。
于是重新配置好所有开机自动挂载信息，将所有出现故障的主机全部重启，该问题暂时解决。
最后提出的处理方法：
