RE: Setting ulimit -n in Solaris Resource Manager

From: Koivu, Lisa <Lisa.Koivu_at_starwoodvo.com>
Date: Tue, 19 Aug 2008 10:14:44 -0400
Message-ID: <7AC0F0BC43539948BE5A63C60295EB0A02F92B2A@SVOEXCPMB01.corp.star>


An aside, in case anyone is interested - setting ulimit -n to a high number exposed bug 6276119, causing the agent to consume 100% of cpu resources and forcing a large load average. Applying this patch addressed the problem.  


From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Koivu, Lisa Sent: Monday, August 18, 2008 9:33 PM
To: oracle-l_at_freelists.org
Subject: Setting ulimit -n in Solaris Resource Manager  

All,  

I'm sending this to everyone because I spent a while stumped on this. I hope it helps someone. (Plus the email serves as documentation)  

I received errors when trying to add my latest cluster database to Grid Control. I kept receiving the error "cannot create targets.xml.old". Searching on this error in meatlink said the filesystem was the problem. It wasn't.  

I looked everywhere to try and find the correct agent log file to search through. There are quite a few sysman directories considering all my oracle homes on these hosts - agent home, crs home, asm home, and dbms home. log file of interest was under
$AGENT_HOME/hostname/sysman/log/emagent.trc. Errors were similar to " error = 24: Too many open files " This led me to check the uname -n setting, which is 4096 across all my hosts.  

I verified there is no hard limit at the system level with ulimit -H, which returned unlimited. Simply increasing the value within the ulimit -n statement in .bash_profile did not work. I received an error "Not owner", basically telling me I need to be superuser to be able to do this. Googling suggested creating a setuid wrapper script to reset this value, or consider adding parameters rlim_fd_cur and rlim_fd_max to /etc/system (which weren't set in the first place, why should I need to add them?)  

While reading up on resource manager again, I noticed that max-file-descriptor is one of the available resource controls. I added a line to the user.oracle project setting the new value to 65535, the value suggested in the meatlink notes I had reviewed. /etc/project now looks like this:  

user.oracle:100::::process.max-file-descriptor=(basic,65535,deny);projec t.max-sem-ids=(priv,256,deny);project.max-shm-memory=(priv,7516192768,de ny)  

I had to comment out the ulimit -n setting in .bash_profile, as I found it was overriding my project setting. Once I did that, signed out, and signed back in, I was able to verify the new value had taken effect.  

The two different privilege levels in the project listed above, basic and priv, merely list who can modify the value. Basic means the owner can modify the value lower within a shell, but can't increase it. Priv means that only superuser can modify the setting within a shell. There is a third setting, system, which means the value only changes at host reboot.  

If I have stated anything incorrectly, please straighten me out!  

I hope this helps someone. I wasted a couple of hours on this.  

Now if I can just get Grid Control to behave!    

Lisa Koivu

Oracle Database Administrator

Starwood Vacation Ownership

Orlando, FL, USA  

This electronic message transmission contains information from the Company that may be proprietary, confidential and/or privileged. The information is intended only for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying or distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify the sender immediately by replying to the address listed in the "From:" field.

This electronic message transmission contains information from the Company that may be proprietary, confidential and/or privileged. The information is intended only for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying or distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify the sender immediately by replying to the address listed in the "From:" field.

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Aug 19 2008 - 09:14:44 CDT

Original text of this message