Java.net. socketexception: Too program open files Solution

Recently, with the increase in website traffic, the web server has been moved to Linux. On the second day of the migration server, Tomcat frequently reports

Java.net. socketexception: The too program open files error. The error log reaches more than 100 mb. It is depressing and runs very long on Windows.

This error was not reported at the time, and later I learned that Linux has a limit on the number of files opened by the process.

Run ulimit-a to view

[Root @ test security] # ulimit-
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] #
Through the above command, we can see that Open Files The maximum number is 1024.

For websites with a large number of concurrent jobs, this restriction is a little too limited, so I use this command

Ulimit-N 4096
Set the maximum number of opened files to 4096. Now the project is stable.

I did not expect this error to happen again in two days. I was depressed and reported it once in two small cases. After reporting it, I got down.

Re-use ulimit-a to view and findOpen Files(-N) 1024 changed back to 1024 again,

This error was reported after my login update. The original ulimit-N 4096 command can only be changed temporarily.Open FilesWhen

It will be restored after login, so you need to set it permanentlyOpen FilesThe value is okay,

Modifying open files with ulimit-N is always not possible. So it is better to use the following simple method.

Modify/etc/security/limits. conf and add the following line:

*-Nofile 1006154

Modify/etc/PAM. d/login and add the following line.

Session required/lib/security/pam_limits.so

After this permanent ModificationProgramThen there is no such problem, and it has been running stably.

In addition, when this problem occurs, we also need to check whether our program closes the IO stream after the operation. This is the most cost-effective solution.