打开文件过多(ulimit已更改)

16
我正在使用Debian服务器,Tomcat 7和Java 1.7。这是一个接收多个TCP连接的应用程序,每个TCP连接都是Java进程打开的文件。
查看/proc/java pid/fd,有时候发现打开的文件数超过1024,当这种情况发生时,在日志中会出现堆栈跟踪_SocketException: Too many open files_ 关于此错误的所有信息,人们都提到了ulimit,我已经更改了这个设置,但错误仍然会发生。以下是配置:
/etc/security/limits.conf中:
root    soft    nofile  8192
root    hard    nofile  8192

/etc/sysctl.conf

fs.file-max = 300000

ulimit -a 命令返回以下信息:

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 16382
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 8192
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

但是,当我检查java进程的限制时,它只有1024个

/proc/java进程的pid/limits中。

Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             32339                32339                processes 
Max open files            1024                 1024                 files     
Max locked memory         65536                65536                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       32339                32339                signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us        

如何增加Java进程的最大打开文件数


排除一下显而易见的情况,Tomcat 是否作为 root 运行? - Brett
3个回答

20

我只是在catalina.sh文件中添加了ulimit -n 8192这行代码,因此当我执行catalina start命令时,Java会按照以上指定的限制来运行。


5
在以这种方式增加ulimit之前,您可能需要在“/etc/security/limits.conf”文件中添加一行。 - Shadow Man
2
我认为我们应该避免修改Catalina。当您升级Catalina时,您可能会忘记在新版本上进行此更改。 - mcoolive
1
据我所了解,limits.conf文件是由PAM在登录时应用的。因此,如果您通过init系统启动Tomcat,则可能无法设置PAM“限制”配置,并且会“回退”到默认值1024。您需要查看init系统手册以了解如何设置此限制。或者使用此处响应中的技巧。 - Huygens
2
就像@mcoolive提到的那样,catalina.sh不是最好的选择。将catalina.sh包装在您自己的脚本中,设置ulimit,然后启动tomcat。这样,当您升级tomcat时,您不会失去ulimit设置。 - threejeez

11

因此,在更改/etc/security/limits.conf后,您需要注销并重新登录(以便您的会话具有新的限制),然后重新启动应用程序。只有这样,您的应用程序才能使用新的限制。


1
提高ulimit的设置可能完全没有必要,这取决于tomcat/httpd处理的工作负载/流量。Linux为每个套接字连接创建一个文件描述符,因此如果tomcat配置为使用mod_jk/ajp协议作为连接器,则您可能需要查看最大允许连接是否过高,或者连接超时或keepAliveTimeout是否过高。这些参数在消耗OS文件描述符方面起着巨大的作用。如果tomcat由反向代理前置,则有时也可以限制apache httpd/nginx连接数。我曾经在httpd中减少serverLimit值以在gaterush场景下调节传入请求。总的来说,调整ulimit可能不是可行的选择,因为您的系统可能会消耗您投入其中的所有资源。您将不得不提出一项全面的计划来解决这个问题。

你好,很抱歉我没有找到其他有用的关于这个问题的信息。你说的“Linux为每个套接字连接创建一个文件描述符”是什么意思?这是否意味着“打开的文件太多”可能是由于同时有太多的传入连接?而mod_jk/ajp协议作为连接器在哪里配置? - ocramot

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接