linux下服务器连接数问题

参考：

http://www.2cto.com/os/201204/126986.html

 

最近我部署的平台，在jmeter测试时，发现，100个连接级出现问题了， 找了半天问题，发现原是操作系统的用户最大连接数问题，

 

查看系统允许打开的最大文件数

 #cat /proc/sys/fs/file-max

 查看每个用户允许打开的最大文件数

 ulimit -a

 发现系统默认的是open files (-n) 1024，问题就出现在这里。

 在系统文件/etc/security/limits.conf中修改这个数量限制，

 在文件中加入内容：

 * soft nofile 65536 

* hard nofile 65536

1.使用ps -ef |grep java   (java代表你程序，查看你程序进程) 查看你的进程ID，记录ID号，假设进程ID为12

2.使用：lsof -p 12 | wc -l    查看当前进程id为12的 文件操作状况

    执行该命令出现文件使用情况为 1052

3.使用命令： ulimit -a    查看每个用户允许打开的最大文件数

    发现系统默认的是open files (-n) 1024，问题就出现在这里。

4.然后执行：ulimit -n 4096

     将open files (-n) 1024 设置成open files (-n) 4096

 这样就增大了用户允许打开的最大文件数，每个ssh连上的用户的设置ulimit是互不干扰的。

 现在我们产品的解决办法是在启动脚本sh里加入ulimit -n 65535

 当然这仅是在必要的时候，一般情况下还要先检查一下文件流的关闭情况。

本以为这样就OK了，但是，发现tomcat服务器也报错：找不到页面了，

才发现tomcat配置中的内存小，还有启动的线程数也不对。

tomcat安装的bin目录下的catalina.sh

添加：export JAVA_OPTS='-Xms4096m -Xmx4096m'

要加“m”说明是MB，否则就是KB了，在启动tomcat时会报内存不足。

-Xms：初始堆值

-Xmx：最大堆值

-Xmn：年轻代大小值

 

 

在tomcat配置文件server.xml中的<Connector ... />配置中，和连接数相关的参数有：
minProcessors：最小空闲连接线程数，用于提高系统处理性能，默认值为10
maxProcessors：最大连接线程数，即：并发处理的最大请求数，默认值为75
acceptCount：允许的最大连接数，应大于等于maxProcessors，默认值为100
enableLookups：是否反查域名，取值为：true或false。为了提高处理能力，应设置为false
connectionTimeout：网络连接超时，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。通常可设置为30000毫秒。

其中和最大连接数相关的参数为maxProcessors和acceptCount。如果要加大并发连接数，应同时加大这两个参数。

web server允许的最大连接数还受制于操作系统的内核参数设置