tomcat报“too many open files”的错误，解决办法如下：

报此错误是由于系统内核对进程打开文件个数的限制，默认为1024
# ulimit -n
1024

修改参数，增大这个限制：

#vi /etc/security/limits.conf

增加下面这一行内容：

* - nofile 65535
将限制增加到65535

注意"nofile"项有两个可能的限制措施。就是项下的hard和soft。 要使修改过得最大打开文件数生效，必须对这两种限制进行设定。 如果使用"-"字符设定, 则hard和soft设定会同时被设定。
硬限制表明soft限制中所能设定的最大值。 soft限制指的是当前系统生效的设置值。 hard限制值可以被普通用户降低。但是不能增加。 soft限制不能设置的比hard限制更高。 只有root用户才能够增加hard限制值。

重启机器使修改配置生效

# ulimit -n
65535

-------------------------------------
为什么发生此问题？

这些异常指出操作系统 (OS) 资源问题和操作系统与 JVM 进程用完文件描述符的原因（请参阅什么是文件描述符？）

在几个并发用户连接到服务器之后通常会发生此问题。Java 打开许多文件，以便读取运行应用程序所必需的类。大量应用程序会使用许多文件描述符，这会导致缺乏新的文件描述符。同样，每个新的套接字都需要一个描述 符。客户端和服务器通过 TCP 套接字进行通信。在与服务器建立连接时，每个浏览器的 http 请求都使用 TCP 套接字。

一定要首先监视文件描述符并了解这些诊断方法如何告知您有关打开文件的状态和其它潜在问题。在针对操作系统逐步执行此故障排除部分之后，可能有必要增加文件描述符的数量
监视文件描述符

解决方法指导原则
下面是一般指导原则和考虑事项：
确定文件描述符的总数是否太少或者某些文件描述符是否未被正确释放。
这可以通过以下方法来诊断：在不同的时期检查文件描述符的总数，确定此数量是有所减少还是一直增加。
如果此数量有所减少，则应当增加文件描述符的最大数量，以防止该问题再次发生（如何在不同平台上定义文件描述符的数量）。
此变化可以和减少连接在断开之前保持 TIME_WAIT 状态的时间结合起来（如何以及何时发布文件描述符？）。在繁忙的服务器上，缺省值（240 秒）会延迟其它连接企图，从而将限制最大连接数量。
如果此数量一直增加，则应当确定某些描述符的处理时间是否过长（文件没有正确地关闭 - 如何以及何时发布文件描述符？）以及所创建的文件是否过多（例如，驱动程序库一直为每个新的 JDBC 连接加载文件）。
加载 jar 文件还可能减少所使用的文件描述符的数量。每个 jar 文件都使用一个描述符，即使每个单独加载的单一类都将使用一个描述符时也是如此。
您可以使用下列指导原则来监视和诊断所有描述符如何由一个进程使用（这取决于您的操作系统）：

检查打开的文件

Unix 平台
在诸多工具中，lsof (LiSt Open Files) Unix 管理工具（适用于 Solaris、Tru64、HP-UX、Linux 和 AIX）显示有关打开文件和网络文件描述符的信息，包括它们的类型、大小和 i-节点。

对于特定的进程，其语法如下所示：


lsof -p <进程的 pid>