max user processes 导致的服务器大量close_wait问题解决过程

1、背景：

由于现网业务量增长过快，需要扩容应用程序服务器，分担来自前端的访问压力。

2、故障：

部署好业务启动程序后，发现程序运行一小会后不产生新的日志和数据。

3、查问题过程：

1、首先查看程序运行有无报错

正常

2、查看服务器的负载，会不会是新增服务器的性能影响了程序正常运行

查看io，正常

top查看，正常

内存使用，正常

3、查看应用服务器和前端nginx 的连接

大量的CLOSE-WAIT

连接状态一看就有问题，CLOSE_WAIT是服务端被动关闭连接的意思（连接状态详解）。

4、解决过程：

网上查解决方法一致都是说程序本身的问题导致，如果你的问题是程序造成的，那么按网上的方法改善代码即可解决。

但是我的新增服务器上的程序都是和原先运行正常的服务器上copy过来的，原服务器运行正常，所以说明不是程序的问题。

从新增服务器本身考虑“被动关闭连接”，会不会是我服务器内核参数配置的连接数太低了。

网上搜的修改连接数的帖子：https://www.jianshu.com/p/fa35d91b727b

经过一番修改，重新启动程序观察，问题依旧，实在是找不到和原有服务器配置上的区别了。

本着所有的问题都是有原因的原则，继续观察端口状态的变化：

观察到一个现象，es状态暴增后突然变为close_wait，应该就是服务器配置限制了连接数，还是要从服务端查看。

经过我的不断努力查找，终于找到问题的原因

root用户和普通用户的ulimit -a查看到的配置是不同的

查看我程序运行账号tomcat 的ulimit（ulimit -a 用来显示当前的各种用户进程限制。）

ulimit -a 时发现max user processes为1024,代表tomcat用户的线程数才1024

修改ulimit -u 65535         //此方法是临时修改

修改永久生效

上面的修改为临时修改，设置永久生效的方式是编辑/etc/security/limits.conf

* soft nproc
* hard nproc
* soft nofile
* hard nofile 

注：sentos6系统中修改/etc/security/limits.conf ,退出shell后重新登陆，依然不行。

报：ulimit: max user processes: cannot modify limit: 不允许的操作 ulimit: open files: cannot modify limit: 不允许的操作

后经Google是/etc/security/limits.d/90-nproc.conf的限制。

解决办法：https://blog.csdn.net/u014595668/article/details/89279756

修改：

# vim /etc/security/limits.d/-nproc.conf
# Default limit for number of user's processes to prevent
# accidental fork bombs.
# See rhbz # for reasoning.
 
*          soft    nproc     unlimited
root       soft    nproc     unlimited

到这里问题终于解决。