决打开文件过多的问题.docVIP

解决打开文件过多的问题无论文件类型是 socket 还是 pipe ，文件描述符对于标志不同类型的打开文件的进程来说是唯一的。当操作系统运行出现文件标志描述符不足时，就会抛出打开文件过多的异常。然而，文件描述符溢出则是更为复杂的问题的征兆，表明与这些文件相关联的资源没有正确被维护。让我们来看看如何诊断导致诸如此类异常的问题： .SocketException: Too many open files at .PlainSocketImpl.accept(Compiled Code) at .ServerSocket.implAccept(Compiled Code) at .ServerSocket.accept(Compiled Code) at weblogic.t3.srvr.ListenThread.run(Compiled Code)和诸如此类的异常： java.io.IOException: Too many open files at java.lang.UNIXProcess.forkAndExec( Native Method) at java.lang.UNIXProcess.( UNIXProcess.java:54) at java.lang.UNIXProcess.forkAndExec( Native Method) at java.lang.UNIXProcess.( UNIXProcess.java:54) at java.lang.Runtime.execInternal( Native Method) at java.lang.Runtime.exec( Runtime.java:551) at java.lang.Runtime.exec( Runtime.java:477) at java.lang.Runtime.exec( Runtime.java:443) ｜ 　　第一个异常在错误影响到底层的 TCP 协议时抛出，而第二个异常则在错误影响到 I/O 操作时抛出。这两个异常都是出现阻塞服务器的类似问题的征兆。该问题可通过下面的研究方法来解决。 　　第二个异常在 JVM 进程缺乏文件描述符时出现（尽管在执行 forkAndExec() 子例程时需要新的文件描述符来复制父进程的文件描述符）。对于每个进程，操作系统内核在 u_block 结构中维护文件描述符表，所有的文件描述符都在该表中建立索引。 　　让我们从复习文件描述符开始。 文件描述符 是由无符号整数表示的句柄，进程使用它来标识打开的文件。文件描述符与包括相关信息（如文件的打开模式、文件的位置类型、文件的初始类型等）的文件对象相关联，这些信息被称作文件的上下文。 　　进程获取文件描述符最常见的方法是通过本机子例程 open 或 create 获取或者通过从父进程继承。后一种方法允许子进程同样能够访问由父进程使用的文件。文件描述符对于每个进程一般是唯一的。当用 fork 子例程创建某个子进程时，该子进程会获得其父进程所有文件描述符的副本，这些文件描述符在执行 fork 时打开。在由 fcntl 、 dup 和 dup2 子例程复制或拷贝某个进程时，会发生同样的复制过程。 　　如果数量下降，我们应该增加文件描述符的最大数量，以防止问题重复出现。这种变化可以与减少连接在断开之前保持 TIME_WAIT 状态的时间长度结合在一起。在繁忙的服务器上， 240 秒的默认值可以延迟其他连接的尝试，因此也限制了连接的最大数量。如果数量持续上升，我们应该确定是否有一些描述符的处理时间过长（文件没有被正确关闭），以及是否创建了过多的文件（例如，驱动程序库不断为每个新的 JDBC 连接加载文件）。 　　加载 JAR 文件也可以减少使用的文件描述符的数量。每个 JAR 文件都使用一个描述符。即使要对每个单一类都使用同一描述符，也必须对每个单一类单独加载。 监视描述符 　　我们可以使用不同的技术，来监控和诊断一个进程是如何使用所有描述符的，不同的技术取决于不同的操作系统。 　　Unix 平台： 在诸多工具中， lsof (LiSt Open Files) Unix 管理工具显示有关打开文件和网络文件描述符的信息，包括它们的类型、大小和 i- 节点。对于特定的进程，其语法如下所示： lsof -p pid of process 　　示例 1 ： 以下命令在 Solaris 2.7 启动 WebLogic Server 8.1SP1 后立即执行。它表明运行服务器的 Java 进程 (PID390) 分配了 84 个文件描述符，此数量远小于文件描述符缺省的硬极限。 -p 390 | wc -l 84 　　这个数字远远低于文件描述符的