Wikipedia

Search results

/etc/security/limits.conf - Shell limits for the oracle User

Setting Shell Limits For Grid and Oracle Users

ulimit is to provide control over system resources. Setting limits to allow the user to use resources as much as really needed. so the system resources can be shared by all users fairly.

To view current ulimit settings by typing the command “ulimit -a”.

$ ulimit -a

The command “ulimit -n” shows the maximum number of open file descriptors.

$ ulimit -n
1024

The command “ulimit -u” shows the maximum number of processes.

$ ulimit -u
2047

Note:

When the limits.conf file is changed, these changes take effect immediately. However, if the grid or oracle users are logged in, then these changes will not take effect until you log these users out and log them back in. You must do this before you attempt to use these accounts to install.

To improve the performance of the software, you must increase the following shell limits for the oracle user:

Shell Limit
Item in limits.conf
Hard Limit
Maximum number of open file descriptorsnofile65536
Maximum number of processes available to a single usernproc16384

How does ulimit work?

Make sure file /etc/pam.d/login contains following line:

session required pam_limits.so

When a user logon, shell loads the pam_limits.so module. The pam_limits.so module is configured to read the file /etc/security/limits.conf. For example, the following lines in /etc/security/limits.conf file for oracle user. GI( grid ) user should have the similar if GI is to be installed and configured.

oracle soft nofile 1024
oracle hard nofile 65536
oracle soft nproc 2047
oracle hard nproc 16384

A soft limit can be increased until it reaches the value of a hard limit. Once a hard limit is set for a value, it cannot be increased further. So the hard limit is the upper cap of restriction for a value. By default, the users specified in /etc/security/limits.conf file DO NOT get the maximum resources as specified by the type “hard”. The users have to request for this explicitly. For this purpose and to enforce the ulimit settings across logins, it is required to edit the file /etc/profile.
Editing this file is also important because shells like bash and ksh may interpret ulimit settings differently. For the Bourne, Bash, or Korn shell, add the following lines in the /etc/profile file (or the /etc/profile.local file on SUSE systems):

if [ $USER = “oracle” ]; then
if [ $SHELL = “/bin/ksh” ]; then
ulimit -u 16384
ulimit -n 65536
else
ulimit -u 16384 -n 65536
fi
fi

For the C shell, add the following lines in the /etc/csh.login file (or the /etc/csh.login.local file on SUSE systems):

if ( $USER == “oracle” ) then
limit maxproc 16384
limit descriptors 65536
endif

Another way to achieve this by setting soft and hard values same in /etc/security/limits.conf:

oracle soft nofile 65536
oracle hard nofile 65536
oracle soft nproc 16384
oracle hard nproc 16384

We also see some users like to configure them in local user profile, for bash shell, edit $HOME/.bash_profile file to copy and paste the following commands for oracle’s bash shell:

su – oracle
cat >> $HOME/.bash_profile << EOF
ulimit -n 65536 -u 16384
EOF

It Is not recommend to set the “hard” limit for nofile for the oracle user equal to /proc/sys/fs/file-max.This may prevent users from logging in as the system cannot open any PAM modules that are required for the login process.

From the above examples, we can see resource limits like the maximum number of user processes can be set from three different places, which are /etc/security/limits.conf, /etc/profile and $HOME/.bash_profile. They have the priority from high to low in order. When setting the ulimit value, we can’t set a bigger value in $HOME/.bash_profile than the value set in /etc/profile as we can’t set a bigger one in /etc/profile than the value set in /etc/security/limits.conf. Otherwise, we could encounter those kind of messages as below:

-bash: ulimit: open files: cannot modify limit: Operation not permitted
-bash: ulimit: max user processes: cannot modify limit: Operation not permitted

No comments:

Post a Comment