File Descriptor Limit

1. We can change the limits by setting the values in the /etc/system file rlim_fd_cur & rlim_fd_max.
2. There is some documentation that states that the mx should never exceed 1024.
3. Question:
a. For Solaris 8 can we ever set the max to be > 1024?
b. If we can, is there another ceiling?
c. Can we redefine FD_SETSIZE in the app that wants to use select() with fds > 1024? Is there any mechanism to do a select() on FDs > 1023?
4. If the process is running at root, does it still have a limit on FDs? Can it then raise it using setrlimit()?
Thnx
Aman

The hard limit is 1024 for number of descriptors.
The man page for limit(1) says that root can
change the hard limits, but if you raise the
limit for fd above 1024 you may encounter kernel
performance or even failure considtions. The number
is a recommendation and emperical based on what a
selection of processors and memory models can
tolerate. You might get more expert info by cross
posting this question to the solaris-OS/kernel
forum. Raising the hard limit might be possible, but
I cannot speak to the risks with much direct
knowledge.
You might want to examine the design of an app that
needs to have more than 1024 files open at once. maybe
there is an alternative design that allows you to
close more file descriptors.

Similar Messages

  • How to increase the per-process file descriptor limit for JDBC connection 15

    If I need JDBC connection more that 15, the only solution is increase the per-process file descriptor limit. But how to increase this limit? modify the oracle server or JDBC software?
    I'm using JDBC thin driver connect to Oracle 806 server.
    From JDBC faq:
    Is there any limit on number of connections for jdbc?
    No. As such JDBC drivers doesn't have any scalability restrictions by themselves.
    It may be it restricted by the no of 'processes' (in the init.ora file) on the server. However, now-a-days we do get questions that even when the no of processes is 30, we are not able to open more than 16 active JDBC-OCI connections when the JDK is running in the default (green) thread model. This is because the no. of per-process file descriptor limit exceeded. It is important to note that depending on whether you are using OCI or THIN, or Green Vs Native, a JDBC sql connection can consume any where from 1-4 file descriptors. The solution is to increase the per-process file descriptor limit.
    null

    maybe it is OS issue, but the suggestion solution is from Oracle document. However, it is not provide a clear enough solution, just state "The solution is to increase the per-process file descriptor limit"
    Now I know the solution, but not know how to increase it.....
    pls help.

  • Set file descriptor limit for xinetd initiated process

    I am starting the amanda backup service on clients through xinetd and we
    are hitting the open file limit, ie file descriptor limit.
    I have set resource controls for the user and I can see from the shell that
    the file descriptor limit has increased, but I have not figured out how to get
    the resource control change to apply to the daemon started by xinetd.
    The default of 256 file channels persists for the daemon, I need to increase
    that number.
    I have tried a wrapper script, clearly doing it incorrectly for Solaris 10/SMF
    services. That route didn't work, or is not as straight forward as it used to be.
    There is a more direct way ?
    Thanks - Brian

    Hi Brian,
    It appears with 32 bits applications. You have to use the enabler of the extended FILE facility /usr/lib/extendedFILE.so.1
    % ulimit -n
    256
    % echo 'rlim_fd_max/D' | mdb -k | awk '{ print $2 }'
    65536
    % ulimit -n
    65536
    % export LD_PRELOAD_32=/usr/lib/extendedFILE.so.1
    % ./your_32_bits_applicationMarco

  • Running Out Of FIle Descriptors "Too many open files"

    We have a 32 application(running on Solaris 8) that opens socket connections and also some files in read/write mode. The application works fine in normal(under low load) case.
    But it is failing under stress environment. At some point under stress environment, when it tries opening a file, it(fopen) gives me error code 24 that means that "too many files opened".
    From this it seems that the application is running out of file descriptors. I used the truss, pfiles and lsof utilities to see how many descriptors are currently opened by my application and the number it gives is around 900(and this is the expected figure to be opened by my application).
    I also set the ulimit(both hard and soft) to a larger number but it also didn't work. Also when i set the soft limit to 70000, the truss output shows like:
    25412/1:     5.3264     sysconfig(_CONFIG_OPEN_FILES)               = 70000
    23123/1: 7.2926 close(69999) Err#9 EBADF
    23123/1: 7.2927 close(69998) Err#9 EBADF
    23123/1: 7.2928 close(69997) Err#9 EBADF
    23123/1: 7.2928 close(69996) Err#9 EBADF
    23123/1: 7.2929 close(69995) Err#9 EBADF
    23123/1: 7.2929 close(69994) Err#9 EBADF
    23123/1: 7.2930 close(69993) Err#9 EBADF
    This goes to close(3).. loops almost 70K times.
    Don't know why such output is.
    Note: under moderate stress environment where only 400 file descriptors are opened, the application works fine.
    can you please help me in this? Is this the file descriptor problem or can be other potential source of problem.
    Is this any other way to increase the file descriptor limit.
    I aldo trying using LD_PRELOAD_32=/usr/lib/extendedFILE.so.1 but it gave me following error while starting application:
    "ld.so.1: ls: fatal: /usr/lib/extendedFILE.so.1: open failed: No such file or direcroty"
    Also i cant use purify(because of some reasons) to find file descriptors leakage(if any) and is not possible to upgrade the system to Solaris 10.
    Thanks in advance.

    http://developers.sun.com/solaris/articles/stdio_256.html

  • Increase file descriptor limits on managed server

    Hi,
    we have an Admin Server which manages a managed server.
    We need to increase file descriptor limits of managed server.
    We modified the script commEnv.sh on Admin server and we successfully increased to 65,536 the limit. Here is the log of the boot of Admin Server
    ####<Sep 25, 2013 11:04:18 AM CEST> <Info> <Socket> <lv01469> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1380099858592> <BEA-000416> <Using effective file descriptor limit of: 65,536 open sockets/files.>
    How can we do the same thing on managed server. We tried to modify the same script (commEnv.sh) on managed server but the file descriptor limits is still 1,024.
    ####<Sep 25, 2013 11:23:30 AM CEST> <Info> <Socket> <lv01470> <119LIVE_01> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1380101010988> <BEA-000415> <System has file descriptor limits of - soft: 1,024, hard: 1,024>
    ####<Sep 25, 2013 11:23:30 AM CEST> <Info> <Socket> <lv01470> <119LIVE_01> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1380101010989> <BEA-000416> <Using effective file descriptor limit of: 1,024 open sockets/files.>
    Thanks in advance

    Solved.
    It was necessary restart Node Manager after modify the commEnv.sh.

  • Cannot reset max-file-descriptor?

    My /var/ad/messages is full of :
    Apr 17 12:30:27 srv1 genunix: [ID 883052 kern.notice] basic rctl process.max-file-descriptor (value 256) exceeded by process 6910
    Even though I have tried to set process.max-file-descriptor set to 4096 for all projects, which appears correct whenever I query any running process, ie:
    srv1 /var/adm # prctl -t basic -n process.max-file-descriptor -i process $$
    process: 2631: -ksh
    NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
    process.max-file-descriptor
    basic 4.10K - deny 2631
    Any ideas...?
    Thanks!!

    Hi,
    Finally found the route cause.
    It is the mistake of the user. In one of his startup scripts(.profile) he is running the command (ulimit -n 1024) which is setting both the soft and hard limits of file descriptors.
    This was the reason, I was unable to increase the file descriptor limit beyond 1024.
    Thanks & Regards,
    -GnanaShekar-

  • Solaris file descriptor question

    Hi,
    We have an application on Solaris 2.6 and
    the shell in which the server runs has a
    file descriptor limit of 1024. What does
    this mean? Does this mean that every process
    from the shell will have 1024 fds? What
    is the maximum # of fds that a solaris 2.6
    system can provide?
    When I run "sysdef", I get:
    ffffffff:fffffffd file descriptors
    How do I interpret this line?
    Is this 64K - some value?
    If system limit is 64K and if each
    shell has 1024, how are the fds allocated
    to the shells?
    What I mean is:
    say I have 3 shells each with descriptor
    limit of 1024, then is the distribution
    something like 1024-2047 for shell 1,
    2048 - 3071 for shell 2 (i.e. 3072) and
    3072 - 4095 for shell 3?
    Appreciate any explanation of this anyone
    can offer.
    thanks,
    mshyam

    Hi There,
    About File Descriptors and Their Limitations:
    All versions of Solaris (including Solaris 7 64-bit) have a default "soft" limit of 64 and a default "hard" limit of 1024.
    Processes may need to open many files or sockets as file descriptors. Standard I/O (stdio) library functions have a defined limit of 256 file descriptors as the fopen() call, datatype char, will fail if it can not get a file descriptor between 0 and 255. The open() system call is of datatype int, removing this limitation. However, if open() has opened 0 to 255 file descriptors without closing any, fopen() will
    not be able to open any file descriptors as all the low-numbered ones have been used up. 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. This allows system functions such as name services, to work as they depend upon stdio routines.
    (See p 368 "Performance and Tuning - Java and the Internet").
    There are limitations on the number of file descriptors
    available to the current shell and its descendents. (See the ulimit man page). The maximum number of file descriptors that can be safely used for the shell and Solaris processes is 1024.
    This limitation has been lifted for Solaris 7 64-bit which can be 64k (65536).
    Therefore the recommended maximum values to be added to /etc/system are:
    set rlim_fd_cur=1024
    set rlim_fd_max=1024
    To use the limit command with csh:
    % limit descriptors 1024
    To use the ulimit command with Bourne or ksh:
    $ ulimit -n 1024
    However, some third-party applications need the max raised. A possible recommendation would be to increase rlim_fd_max, but not the default (rlim_fd_cur). Then rlim_fd_cur can be raised on a per-process basis if needed, but the higher setting
    for rlim_fd_max doesn't affect all processes.
    I hope this helps your understanding about systemwide file descriptor max limit in conjunction with shell and per process file descriptor limits.
    ....jagruti
    Deveoper Technical Support
    Sun Microsystems Inc.

  • Change 'Soft Resource Limit file descriptor' value

    Hi,
    How do I change 'Soft Resource Limit file descriptor; value in Solaris 10
    Is there any conditions to change this?
    Ashraf.

    There are 2 values. The default and the maximum.
    It starts at the default and can be increased up the maximum.
    If you want change the value persistently and machine wide, you can put a config option
    in /etc/system. Something like
    set rlim_fd_cur = 8129
    set rlim_fd_max = 8129
    If you want to do it for your account only then, just put those lines into your profile.
    But you'll still be only able to increase it up to the max.
    The max can only be increased by root or in /etc/system.

  • Failed to start essbase process:  number of back up files exceeds limit

    Can someone help to take a look at this?
    More details is logged in bug 11887650
    Failed to start essbase process, message in log file:
    11/03/18 11:44:10 Start process
    Info: Essbase is reducing the number of soft file descriptors because the 32K limit has been exceeded. Exceeding the limit may significantly increase application load time.
    Environment variable [HYPERION_LOGHOME] is set - use it to define Log location folder.
    Log location is [u01/APPLTOP/instance/BIInstance/diagnostics/logs/Essbase/essbaseserver3/essbase].
    ODL log location is [u01/APPLTOP/instance/BIInstance/diagnostics/logs/Essbase/essbaseserver3/agent-log].
    [Fri Mar 18 11:44:10 2011]Local/ESSBASE0///4072736080/Warning(1056807)
    The number of back up files found on disk (40) exceeds the configured limit which is 2
    [Fri Mar 18 11:44:10 2011]Local/ESSBASE0///4072736080/Info(1051283)
    Retrieving License Information Please Wait...
    [Fri Mar 18 11:44:10 2011]Local/ESSBASE0///4072736080/Info(1051286)
    License information retrieved.
    65535 Essbase user 65535 Planning user system
    Logging configuration class "oracle.core.ojdl.logging.LoggingConfiguration" failed
    oracle.core.ojdl.logging.LoggingConfigurationException: ODL-52050: unable to process file '/u01/APPLTOP/instance/BIInstance/Essbase/essbaseserver3/bin/logging.xml', XML parse exception (line: 5, column: 38): org.xml.sax.SAXParseException: Attribute "class" is required and must be specified for element type "log_handler".
    Mar 18, 2011 11:44:14 AM oracle.security.jps.az.internal.common.scanner.PolicyChangeScannerThread run
    INFO: Policy store cleanup thread started.
    Mar 18, 2011 11:44:14 AM
    INFO: EPMCSS-CSS Fusion system initialized successfully. : [2724 ms]
    [Fri Mar 18 11:44:14 2011]Local/ESSBASE0///4072736080/Info(1051199)
    Single Sign-On Initialization Succeeded !
    [Fri Mar 18 11:44:14 2011]Local/ESSBASE0///4072736080/Info(1051639)
    Info: Essbase is reducing the number of soft file descriptors because the 32K limit has been exceeded. Exceeding the limit may significantly increase application load time.
    Essbase 64-bit - Release 11.1.2 (ESB11.1.2.1.0B154)

    I am an infrastructure idiot (I have all kinds of other idiocy available as well -- I am versatile), but I found:
    http://troubleshooot.wordpress.com/2010/05/26/essbase-login-is-not-working/
    To my ignorant eyes, this looks like some kind of *nix-centric issue.
    If the post doesn't help, perhaps one of the infrastructure guys will chime in.
    Regards,
    Cameron Lackpour

  • File descriptor setting

    We are using iDS 5.1 sp2 running on solaris 8. We have idar with 2 ldap server on back(1 master, 1 slave).
    We didnt't setup the max connection for iDAR, which mean unlimited connection is allowed. However, the unix system ulimit setting was 256, which is too low. I changed the setting under /etc/system and rebooted the unix.. Then the ulimit setting is 4096 for both hard limit and soft limit. It looks good.
    However, whenever the total connection to iDAR approaching 256, fwd.log file will show that "socket closed". The iDAR is still available, but the socked is used up.
    I have been wondering why the new setting didn't take effect for iDAR.
    Can anybody help me or give me some clue?
    Thanks!

    Hi,
    Welcome to oracle forums :)
    User wrote:
    Hi,
    We are running Solaris 10 and have set project for Oracle user id. When I run prctl for one of running process, I am getting >below output.
    process.max-file-descriptor
    basic 8.19K - deny 351158
    privileged 65.5K - deny -
    system 2.15G max deny -
    My question is whats the limit for process running under this project as far as max-file-descriptor attribute is concerned? Will it >be 8.19K or 65.5K or 2.15G? Also what is the difference among all three. Please advice. Thanks.Kernel parameter process.max-file-descriptor: Maximum file descriptor index. Oracle recommends *65536*
    For more information on these settings please refer MOS tech note:
    *Kernel setup for Solaris 10 using project files. [ID 429191.1]*
    Hope helps :)
    Regards,
    X A H E E R

  • Max number of file descriptors in 32 vs 64 bit compilation

    Hi,
    I compiled a simple C app (with Solaris CC compiler) that attempts to open 10000 file descriptors using fopen(). It runs just fine when compile in 64-bit mode (with previously setting �ulimit �S -n 10000�).
    However, when I compile it in 32-bit mode it fails to open more than 253 files. Call to system(�ulimit �a�) suggests that �nofiles (descriptors) 10000�.
    Did anybody ever see similar problem before?
    Thanks in advance,
    Mikhail

    On 32-bit Solaris, the stdio "FILE" struct stores the file descriptor (an integer) in an 8-bit field. WIth 3 files opened automatically at program start (stdin, stdout, stderr), that leaves 253 available file descriptors.
    This limitation stems from early versions of Unix and Solaris, and must be maintained to allow old binaries to continue to work. That is, the layout of the FILE struct is wired into old programs, and thus cannot be changed.
    When 64-bit Solaris was introduced, there was no compatibility issue, since there were no old 64-bit binaries . The limit of 256 file descriptors in stdio was removed by making the field larger. In addition, the layout of the FILE struct is hidden from user programs, so that future changes are possible, should become necessary.
    To work around the limit, you can play some games with dup() and closing the original descriptor to make it available for use with a new file, or you can arrange to have fewer than the max number of files open at one time.
    A new interface for stdio is being implemented to allow a large number of files to be open at one time. I don't know when it will be available or for which versions of Solaris.

  • Idle File Descriptors

    Hello:
    We recently upgraded from WLS 7.01 to WLS 8.1. One thing we have encountered
    is an effective crash of the WebLogic server given that WebLogic appears to not
    be releasing idle TCP connections. We specifically are seeing idle file descriptors
    (using lsof -p) which remain idle for days (far exceeding any timeout settings
    on the Solaris machine). In addition, when all descriptors are used (current
    limit is 1024), we receive a socket exception (java.net.SocketException: Too many
    open files).
    We have contacted BEA support and received a response of 'network configuration
    is the issue'. We are highly skeptical of the response given that we have changed
    nothing in our network configuration between 7.0 and 8.1. In addition, we recently
    interrogated some production environments running 7.0 and found a small number
    of idle file descriptors. Overall it appears that the idle file descriptor problem
    is amplified in 8.1. Has any else encountered this behavior?
    Finally we are not in a position to restart production instances on a periodic
    basis. We have service level agreements to achieve and kicking our customers
    out of the product on a routine basis is not even close to being acceptable.
    Any thoughts or ideas from the group would be sincerely appreciated.
    Brian

    Hi,
    Have you managed to sort this yet, we are getting the same error in HPUX running
    BEA 6.1 - would be good if you could email me a resolution if you found one.
    thanks

  • Overcoming file descriptor limitation?

    Hello,
    I am developing a server, which should be able to handle more than 65535 concurrent connections. I have it implemented in Java, but I see limit in file descriptors. Since there is no fork() call in Java, I can't find out what to do.
    The server is basically some kind of HTTP proxy and the connection often waits for upstream HTTP server to handle the connection (which can take some time, during which I need to leave the socket open). I made a simple hack, which helped me, I used LD_PRELOAD to catch bind() library call and set Linux socket option TCP_DEFER_ACCEPT
                    if (setsockopt(sockfd, IPPROTO_TCP, TCP_DEFER_ACCEPT, (char *)&val, sizeof(int)) < 0) ....This tells kernel to accept() connection only when there's some data there, which helps a little (sockets waiting for handshake and request to come don't have to consume file descriptor). Any other hints? Should I somehow convince java to fork()? Or should I switch to 64-bit kernel and 64-bit java implementation?
    I can quite easily switch to Solaris if that would help.
    Any pointers/solutions appreciated.
    Juraj.

    You can use dbms_lob functions to access CLOBS, so changing the datatype may not be as problematic as you think.
    Also, in PL/SQL the VARCHAR2 limit is 32767, not 4000, so if you're accessing the table via a stored procedure you can change the column datatype to CLOB. Provided the data is less than 32767 in length you can use a PL/SQL variable to manipulate it.
    Incidentally, use CLOB not LONG for future compatibility.

  • Want to increase the file descriptors

    Hi,
    I am trying the increase the max number for file descriptor allowed in Solaris.
    I changed the ulimit soft value to hard limit value (65536) as a root.Even the ulimit -a shows the change value for the soft limit.
    When I run my test program to find the value of sysconf(_SC_OPEN_MAX) it shows the changed value.But when I try to open more than 253 files it fails.How do I increase this, also when I change the ulimit -n 65536 why the max number for files open is not increased.
    Looking forward for help.
    Thanks in advance
    -A

    The simplest workaround is to compile as a 64bit executable.
    -m64 in gcc. I don't remember offhand what the option is for Sun CC.
    The difficulty is that any non system libraries your using will also need to be recompiled to be 64 bit..

  • Stdio - file descriptor limits - Solaris 10

    Hi
    New to Solaris from HP-UX and we are porting an application.
    I run into a problem whereby we run out of file descriptors - application is TCP/IP and file I/O intensive. Sometimes it happens, sometimes not.
    It manifests itself as an error when calling setsockopt.
    Increasing the file limits in /etc/system has not relieved the problem.
    A google suggests there is a hard limit of 255 on file descriptors for 32-bit applications using stdio - does this still apply? Any workarounds?
    Specs:
    Solaris 10 01/06
    SunOS saturn 5.10 Generic_118822-25 sun4u sparc SUNW,Sun-Fire-v240
    Thanks in advance.

    What shell do you start the application from?
    If you use sh/bash/ksh; type "ulimit -a" too see what limits the process will inherit from the shell, if the value for 'open files' is very low you can increase it with:
    ulimit -n <new value>
    for example;
    ulimit -n 4096
    if you are using tcsh/csh type "limit -h" to view the limits.
    The values you set in /etc/system is the maximum allowed amount of file descriptors per process, it means that the process is allowed to increase its own limit of open files til that limit, but it doesn't mean that the process gets the highest limit automatically.
    See also:
    man ulimit
    man setrlimit
    7/M.

Maybe you are looking for