工作小记——应用启动时，机器宕机

症状：新上的项目，应用一启动，没多久直接宕机。远程连接也连不上，只能云后台重启

线索：

（1）项目没对外发布，没有入口有大流量涌入。除了测试人员个别点击。

（2）反查宕机前的CPU，内存，IO等资源信息，全都不高。

（3）测试环境完全不会发生

查错：

（1）在业务日志的报错信息中，出现了大量dubbo调用时的报错：OutOfMemoryError：unable to create new native thread

（2）一般出现这种错误，是JVM不断创建线程，每个线程栈256K（举例），且并不属于JVM启动时申请的堆内存。直到把内存耗尽。但是从宕机前的内存情况来看，不像

（3）百度后，发现可能是ulimit -u参数限制。测试环境因为为root用户，该数为65535，生产环境为普通用户，该数为4096

（4）然，大部分百度解释ulimit -u参数为单个用户最大进程数。如果是进程的话，该用户才起了个位数的进程，不可能突破4096。小部分提到是单个用户最大进程或线程数

初步结论：生产环境ulimit -u的参数配置不够，导致宕机

验证目的：

（1）ulimit -u限制的确实是线程数，而非进程数

（2）系统为合理使用，并非代码Bug导致线程数超4096

（3）用户创建线程数超设定值时，机器确实会产生宕机情况

验证过程：

（1）测试环境手动将参数配置成500。在/etc/security/limits.d/20-nproc.conf(centos6 是90-nproc.conf) 文件里将*   soft    nproc  那行的数字改掉

（2）启动应用，观察   pstree -p |wc -l (全部线程数)    pstree -p [应用pid]  |wc -l (某进程的线程数)

（3）当线程数超阈值时，发生宕机

（4）检查生产上同一台机器上别的应用，dubbo配置了3000个工作线程，新项目配置了1000的工作线程。

结论：

　　1.单用户创建线程数超ulimit -u的设置，会导致宕机

　　2.别的项目配置了3000个dubbo工作线程，加上50个dubbo的io线程（貌似）。新项目配置了1000个dubbo工作线程，加上50个dubbo的io线程。再加上点别的，总共大概会开4100+的线程，将将超过4096的阈值。属于正常使用

措施：

　　通过修改/etc/security/limits.d/20-nproc.conf(centos6 是90-nproc.conf) 文件加大单用户线程数