RE: Setting ulimit -n in Solaris Resource Manager

  • From: "Koivu, Lisa" <Lisa.Koivu@xxxxxxxxxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Tue, 19 Aug 2008 10:14:44 -0400

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@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Koivu, Lisa
Sent: Monday, August 18, 2008 9:33 PM
To: oracle-l@xxxxxxxxxxxxx
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. 

Other related posts: