用ulimit -a命令查看目前系统的所有限制，ulimit -n查看open files的限制

其中“open files (-n) 1024”就是Linux操作系统对一个进程打开的文件句柄数量的限制，也包含打开的SOCKET数量（特别是很讨厌close_wait和time_wait状态，用netstat命令查看），所以会影响MySQL或服务器的并发连接数目。这个值可用ulimit命令来修改，用ulimit命令要有root用户权限

可见，open files的最大值已经被修改了，但ulimit命令修改的数值只对当前登录用户的目前使用环境有效,系统重启或者用户退出后就会失效

linux 上tomcat 服务器抛出socket异常“文件打开太多”的问题 
java.net.SocketException: Too many open files
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
at java.net.ServerSocket.implAccept(ServerSocket.java:450)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:60)
at org.apache.tomcat.util.net.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoint.java:407)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:70)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595) 
原本以为是tomcat的配置或是应用本身的问题，"谷歌"一把后才发现，该问题的根本原因是由于系统文件资源的限制导致的。
具体的解决方式可以参考一下：
1。ulimit -a 查看系统目前资源限制的设定。
[root@test security]# ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
max locked memory     (kbytes, -l) unlimited
max memory size       (kbytes, -m) unlimited
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 7168
virtual memory        (kbytes, -v) unlimited
[root@test security]# 
通过以上命令，我们可以看到open files 的最大数为1024
那么我们可以通过一下命令修改该参数的最大值
2. ulimit -n 4096
[root@test security]# ulimit -n 4096
[root@test security]# ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
max locked memory     (kbytes, -l) unlimited
max memory size       (kbytes, -m) unlimited
open files                    (-n) 4096
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 7168
virtual memory        (kbytes, -v) unlimited
这样我们就修改了系统在同一时间打开文件资源的最大数，基本解决以上问题。

报这个错误就在我那次登陆更新之后又报的，原来ulimit -n 4096 命令只能临时的改变open files 的值，当重新登陆后又会恢复，所以需要永久设置open files 的值才行啊，用ulimit -n 修改open files 总是不能保持。所以用下面一个简单的办法更好些。
修改/etc/security/limits.conf 
添加如下一行：* - nofile 65536

修改/etc/pam.d/login
添加如下一行session required /lib/security/pam_limits.so

退出shell登陆，重新登陆一次即生效(运行ulimit -n 检查)

Tomcat Too Many Open Files ;Too many open files tomcat 6.0报“too many open files Too many open files 问题的解决 linux 故障解决，tomcat 故障处理，too many open files 故障处理
发表于 2011 年 01 月 06 日 由 admin 
Tomcat Too Many Open Files ;Too many open files tomcat 6.0报“too many open files Too many open files 问题的解决

linux 故障解决，tomcat 故障处理，too many open files 故障处理这个问题是第一次在Linux环境下碰到，把解决的方法记录下来。服务器配置：两个双核CPU 2.0G，4G内存
操作系统：CentOS，内核2.6.18

应用1、搜索服务器，负责全站的搜索和提供内容相关性接口应用服务器：Tomcat6.0.16+Apache2.2.8，其中两个Tomcat实例，一个对外提供服务，一个对内管理索引(创建、删除、检索等)
Web方案：Solr1.3(With Solr Client For Java)、Java Servlet(Web Service 接口)

应用2、类似于百度知道的一个应用
应用服务器：与搜索服务器共享Apache2.2.8
Web方案：Php+Mysql

问题症状：搜索服务停止，应用2响应超时，牵连全站的搜索接口调用内容的输出，查看Catalina日志，大量的如下信息：


Java代码
org.apache.jk.common.ChannelSocket acceptConnections
WARNING: Exception executing accept
java.net.SocketException: Too many open files
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(Unknown Source)
at java.net.ServerSocket.implAccept(Unknown Source)
at java.net.ServerSocket.accept(Unknown Source)
at org.apache.jk.common.ChannelSocket.accept(ChannelSocket.java:295)
at org.apache.jk.common.ChannelSocket.acceptConnections(ChannelSocket.java:641)
at org.apache.jk.common.SocketAcceptor.runIt(ChannelSocket.java:852)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Unknown Source) 

org.apache.jk.common.ChannelSocket acceptConnections
WARNING: Exception executing accept
java.net.SocketException: Too many open files
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(Unknown Source)
at java.net.ServerSocket.implAccept(Unknown Source)
at java.net.ServerSocket.accept(Unknown Source)
at org.apache.jk.common.ChannelSocket.accept(ChannelSocket.java:295)
at org.apache.jk.common.ChannelSocket.acceptConnections(ChannelSocket.java:641)
at org.apache.jk.common.SocketAcceptor.runIt(ChannelSocket.java:852)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Unknown Source)


使用如下命令查看系统对允许打开最大文件描述符的配置：
ulimit -u 查看open files设置
ulimit -a 查看所有设置
ulimit -u 65535(新的open files 值)修改设置
ulimit -n 65536 设置用户可以同时打开的最大文件数（max open files）

如果本参数设置过小，对于并发访问量大的网站，可能会出现too many open files的错误  
使用lsof -p pid [httpd进程的 pid、java的pid]来查看系统中apache进程和java运行时进程当前打开的文件资源，发现两者之和已经接近1024，大于了默认的设置。

修改配置：

修改/etc/security/limits.conf，在文件末加上
* soft nofile 65536
* hard nofile 65536

系统级文件描述符极限还可以通过将以下三行添加到 /etc/rc.d/rc.local 启动脚本中来设置：
# Increase system-wide file descriptor limit.
echo 65536 > /proc/sys/fs/file-max
echo 65536 > /proc/sys/fs/inode-max 
虽 然调整该参数解决了当前的问题，但并不是最好的方法，出现该错误说明该服务器承载了一定的并发连接，尤其是搜索服务，其中一个实例对外提供搜索，另一个实 例创建索引，两个实例之间也使用socket进行通信(httpclient for java)，创建索引的时候会占用大量的文件描述符，如果描述符没有及时释放(不能完全依赖垃圾回收机制，要及时的close)；全站的所有与搜索有关的 接口调用都会向其发出请求，而应用2也对外服务不少的请求，较好的办法是将搜索服务从该服务器中分离出来，这样可以分别对两者进行优化(包括调整 Linux系统参数，比如：/etc/sysctl.conf中对net.ipv4的优化)，出了问题也容易debug

最大的可能是打开的文件或是socket没有正常关闭。

通过Java进程号查看当前进程占用文件描述符情况：

lsof -p $java_pid 每个文件描述符的具体属性  

lsof -p $java_pid | wc -l  当前Java进程file descriptor table中FD的总量  

lsof -p $java_pid 每个文件描述符的具体属性 lsof -p $java_pid | wc -l  当前Java进程file descriptor table中FD的总量

分析命令的结果，可判断问题是否由非正常释放资源所引起。