Settings for Solaris 2.5.1 /etc/system rlim_fd_cur and S un Infodoc 11915
2007-12-25 9:54:00
It seems possible to set rlim_fd_cur with a value above 256 (max of 1024) in
/etc/system for Solaris 2.5.1 kernel. And, no one responded with info on
SunSolve Infodoc 11915.
OS:
Sun Solaris 2.5.1
HARDWARE:
Sparc
ORIGINAL QUESTIONS:
Q1: What has been others experiences with setting rlim_fd_cur above a value
256 in /etc/system for Solaris 2.5.1 kernel?
Q2: Does anyone have a copy of SunSolve Infodoc 11915? I can't find it on
SunSolve.
DETAILS:
My Sybase backup dB SQL server started having problems with dump and loads
after the software Sybase SQL Backtrack was loaded. The DBA thinks it is a
problem with a raw hd device. I am thinking differently. After their deep
research (they are most familiar with HPs) they asked what my "max file
descriptions" was set to. A review of the system showed it was set to 1024
via /etc/system rlim_fd_cur. A review of the systems build notes shows this
value was requested by Sybase.
Another UA here pointed out to me that in the book "Sun Performance and
Tuning" page 557, the max setting for rlim_fd_cur is 256 and values over 256
breaks stdio and says see SunSolve Infodoc 11915 for further details.
I could not find Infodoc 11915 on SunSolve.
SUMMARY OF MY SOLUTION:
Problem turned out to be that backup SQL Sybase dB server is a bit
undersized (SS20 w/ one ROSS 200 backing up a U3000 w/ two 168) for what we
were asking it to do. It was discovered that each time problem occur,
unknown to me, a new DBA was also running a large DBCC on the backup server
at the same time that the Primary dB server was trying to sync to the backup
dB server. We normally don't do DBCC on the backup dB server but the new
DBA was in his efforts to debug why the just installed software of "Sybase
SQL Backtrack" would backup all dBs but one.
Both systems are schedule for replacement by identical U5500 later this
year. In mean time RAM is backup dB server will be increased from 256mb to
512mb and no DBCCs will be ran during sync times. If problem comes back (it
is not expected too)before U5500 then add a second ROSS 200 cpu.
SUMMARY ON RLIM_FD_CUR:
Got mixed response on whether or not /etc/system rlim_fd_cur could or could
not be set to a value over 256. Sybase definitely recommends it. SunSolve
Infodoc 21622 had some info on "file descriptors" and their "limitations"
with /etc/system rlim_fd_cur which I understand to mean...
The default value of 256 for "file descriptors" can be set to 1024 as long
as standard I/0 is not forced to use position 255 thru 1023. "file
descriptors" is used by standard I/O (stdio) library functions [fopen(),
datatype char, open()] and will fail if it can not get a file descriptor
between 0 and 255.
Applications that need to use many "file descriptors" to open a large number
of sockets, or other raw files, should be forced to use descriptors numbered
above 256 so as not to mess with the mind of standard I/O. The max number
of file descriptors for the shell is 1024 for Solaris 7 32-bit and under,
for Solaris 7 64-bit and above the max limit of 65536 can be achived by
redefining FD_SETSIZE and recompiling OS and app with a 64-bit complier.
So Solaris 2.5.1 thru Solaris 7 32-bit can support maximum values of 1024 in
/etc/system of:
set rlim_fd_cur=1024
set rlim_fd_max=1024
Once the above is done, to use the limit command with csh do "limit
descriptors 1024". For Bourne or ksh do "ulimit -n 1024".
RESPONSES RECEIVED:
Nickolai Zeldovich reports...
I'm running one machine with rlim_fd_max=rlim_fd_cur=4096. Runs fine. We've
seen problems when going over 16K or 32K (can't remember which) though.
Casper Dik reports...
The "cur" or soft limit of over 256 in itself doesn't' break stdio; however,
stdio cannot use file descriptors over 255 and if a application exceeds the
256 limit, it can no longer open files using fopen/popen etc.
Note: that using a value over 1024 *will* cause breakage, as no RPC servers
will work in Solaris 2.5.1 and before.
John Benjaminus reports that has no problem running with the following
settings...
set rlim_fd_max = 2048
set rlim_fd_cur = 256
THANK YOU:
I would like to thank the following for their responses,
Nickolai Zeldovich <kolya@zepa.net>
Casper Dik <Casper.Dik@holland.sun.com>
john benjamins <johnb@Soliton.COM>
FROM:
Chris O'Neal <onealwc@agedwards.com>
DATE:
04-17-2000
***************************************************************************************
WARNING: All e-mail sent to and from this address will be received or
otherwise recorded by the A.G. Edwards corporate e-mail system and is
subject to archival, monitoring or review by, and/or disclosure to,
someone other than the recipient.
***************************************************************************************
Comments
Got something to say?
You must be logged in to post a comment.
