问题现象

这是一个基于 java 的 web 应用系统，在后台添加数据时提示无法添加，于是登陆服务器查看 tomcat 日志，发现如下异常信息：

java.io.IOException: Too many open files

通过这个报错信息，基本判断是系统可以用的文件描述符不够了，由于 tomcat 服务室系统 www 用户启动的，于是以 www 用户登陆系统，通过 ulimit –n 命令查看系统可以打开最大文件描述符的数量，输出如下：

$ ulimit -n65535复制代码

可以看到这台服务器设置的最大可以打开的文件描述符已经是 65535 了，这么大的值应该够用了，但是为什么提示这样的错误呢？

解决思路

这个案例涉及 ulimit 命令的使用。

在使用 ulimit 时，有以下几种使用方法：

1 在用户环境变量中加入

如果用户使用的是 bash，那么可以在用户目录的环境变量文件. bashrc或者.bash_profile中加入 ulimit –u128来限制用户最多可以使用 128 个进程

2 在应用程序的启动脚本中加入

如果应用程序是 tomcat，那么可以在 tomcat 的启动脚本 startup.sh 中加入ulimit -n 65535限制用户最多可以使用 65535 个文件描述符

3 直接在 shell 命令终端执行 ulimit 命令

这种方法的资源限制仅仅在执行命令的终端生效，在退出或者和关闭终端后，设置失效，并且这个设置不影响其他 shell 终端

解决办法

在了解 ulimit 知识后，接着上面的案例，既然 ulimit 设置没有问题，那么一定是设置没有生效导致的，接下来检查下启动 tomcat 的 www 用户环境变量是否添加 ulimit 限制，检查后发现，www 用户并无 ulimit 限制。

于是继续检查 tomcat 启动脚本 startup.sh 文件是否添加了 ulimit 限制，检查后发现也没有添加。最后考略是否将限制加到了 limits.conf 文件中，于是检查 limits.conf 文件，操作如下：

# cat /etc/security/limits.conf | grep wwwwww soft nofile 65535www hard nofile 65535复制代码

从输出可知，ulimit 限制加在 limits.conf 文件中，既然限制已经添加了，配置也没有什么错，为何还会报错，经过思考，判断只有一种可能，那就是 tomcat 的启动时间早于 ulimit 资源限制的添加时间，于是首先查看下 tomcat 启动时间，操作如下：

# uptimeUp 283 days# pgrep -f tomcat4667# ps -eo pid,lstart,etime|grep 46674667 Sat Jul 6 09;33:39 2013 77-05:26:02复制代码

从输出可以看出，这台服务器已经有 283 没有重启了，而 tomcat 是在 2013 年 7 月 6 日 9 点启动的，启动了将近 77 天，接着继续看看 limits.conf 文件的修改时间，

[root@localhost]# stat /etc/security/limits.conf   File: ‘/etc/security/limits.conf’  Size: 2508      	Blocks: 8          IO Block: 4096   regular fileDevice: fd01h/64769d	Inode: 1179853     Links: 1Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)Access: 2013-07-12 12:20:01.565327377 +0800Modify: 2013-07-12 12:00:08.964956856 +0800Change: 2013-07-12 12:00:08.964956856 +0800 Birth: -