Load error : file 'set_symbol.so' "Too many open files in system"; etc.
- Article Type: General
- Product: Aleph
- Product Version: 20
Description:
On our upgraded test server, libtstdb, I've been running the various indexing procs in ABC01. P_manage_02 seems to have stalled, with numerous errors such as this from p_manage_02_c.log:
Load error : file 'set_symbol.so'
error code: 198, pc=0, call=1, seg=0
198 error message text not found (Too many open files in system)
Load: /exlibris/aleph/u20_2/alephe/tab/tab100
Load: /exlibris/aleph/u20_2/abc01/tab/tab100
Oracle error: handle_connection
Error while trying to retrieve text for error ORA-12560
Can't make pipe.
Resolution:
There are three different system settings which relate to open files. Below, I compare the settings on your server to those on the Ex Libris v20 server and two other customers' v20 servers. (All of these servers are Linux servers.)
1. /proc/sys/fs/file-max:
On your server, this is 16384, while on the Ex Libris v20 server it's 65536.
On customer #1's server, it's 6553600.
On customer #2's server, it's 32767.
2. the fs.file-max line in /etc/sysctl.conf:
On your server, this is 6553600, while on our server, it's 65536.
On customer #1's server, it's 6553600.
On customer #2's server, it's 65536.
3. the "nofile" (number of files) line in /etc/security/limits.conf.
Your server's limits.conf has no such line.
Our server's limit.conf has:
oracle hard nofile 65536
Customer #1 server's limits.conf has no such line.
Customer #2 server's limit.conf has:
oracle hard nofile 65536
I am forwarding this problem/question to our Installation team.
If you want to do something immediately, I believe that the following settings may not be perfect, but will be better than what you have, and may correct this problem:
1. Increase /proc/sys/fs/file-max to 65536.
2. Reduce the fs.file-max in /etc/sysctl.conf to 65536.
3. Add this line to /etc/security/limits.conf:
oracle hard nofile 65536
In addition, KB 16384-8401 describes a relation between the "Too many open files" error and "limit descriptors". I find that "limit descriptors" on your server gives the same result as on the Ex Libris v20 server (32767):
aleph@libtstdb(a20_2):~/a20_2/alephm>limit descriptors
descriptors 32767
Therefore, it doesn't seem that "limit descriptors" is a factor in this case.
[From Installation team:]
The current AIK version includes the correct values in /etc/sysctl.conf
This is described in the "Linux Servers" section of the Aleph Installation Kit.pdf, on the Doc Portal.
[From site:]
Everything seems to be fine.
- Article last edited: 10/8/2013