Home > Solaris > How to Tune kernel parameters in Solaris 10

How to Tune kernel parameters in Solaris 10

Solaris 10 has introduced a lots of new features and one of them is to tune the kernel without rebooting the system. So that you can modify the kernel in a live production system. Many kernel parameters have been replaced by so called resource controls in Solaris 10. It is possible to change resource controls using the prctl command. All shared memory and semaphore settings are now handled via resource controls, so any entries regarding shared memory or semaphores (shm & sem) in /etc/system will be ignored. Before going into details let us check what is semaphore.

Shared memory and semaphores are two important resources for many applications like Oracle on Unix. An instance cannot start if it is unable to allocate what it needs.

Shared memory is exactly that – a memory region that can shared between different processes. Oracle uses shared memory for implementing the SGA, (System Global Area (SGA) is a group of shared memory areas that are dedicated to an Oracle “instance”) which needs to be visible to all database sessions. Semaphores can be thought of as flags (hence their name, semaphores). They are either on or off. A process can turn on the flag or turn it off. If the flag is already on, processes who try to turn on the flag will sleep until the flag is off. Upon awakening, the process will reattempt to turn the flag on, possibly suceeding or possibly sleeping again. Such behaviour allows semaphores to be used in implementing a post-wait driver – a system where processes can wait for events (i.e. wait on turning on a semphore) and post events (i.e. turning of a semaphore). This mechanism is used by Oracle to maintain concurrency control over the SGA, since it is writeable by all processes attached.

Here is the procedure we followed to modify the kernel parameters on Solaris 10 / Oracle 10.2.0.2.

Unlike earlier releases of Solaris, most of the system parameters needed to run Oracle are already set properly, so the only one you need is the maximum shared memory parameter. In earlier versions this was called SHMMAX and was set by editing the /etc/system file and rebooting. With Solaris 10 you set this by modifying a «Resource Control Value». You can do this temporarily by using prctl, but that is lost at reboot so you will need to add the command to the oracle user’s .profile.

The other option is to create a default project for the oracle user.

# projadd -U oracle -K \
  "project.max-shm-memory=(priv,4096MB,deny)" user.oracle

What this does:

  • Makes a project named “user.oracle” in /etc/project with the user oracle as it’s only member.

# cat /etc/project

system:0::::
user.root:1::::
noproject:2::::
default:3::::
group.staff:10::::
user.oracle:100::oracle::project.max-shm-memory
=(priv,4294967296,deny)

  • Because the name was of the form “user.username” it becomes the oracle user’s default project.
  • The value of the maximum shared memory is set to 4GB, you might want to use a larger value here if you have more memory and swap.
  • No reboot is needed, the user will get the new value
    at their next login.

Now you can also modify the max-sem-ids Parameter:

# projmod -s -K “project.max-sem-ids=(priv,256,deny)” \
user.oracle

Check the Paramters as User oracle

$ prctl -i project user.oracle

project: 100: user.oracle
NAME    PRIVILEGE       VALUE    FLAG   ACTION RECIPIENT
project.max-contracts
privileged      10.0K       -   deny           -
system          2.15G     max   deny           -
project.max-device-locked-memory
privileged       125MB      -   deny           -
system          16.0EB    max   deny           -
project.max-port-ids
privileged      8.19K       -   deny           -
system          65.5K     max   deny           -
project.max-shm-memory
privileged      4.00GB      -   deny           -
system          16.0EB    max   deny           -
project.max-shm-ids
privileged        128       -   deny           -
system          16.8M     max   deny           -
project.max-msg-ids
privileged        128       -   deny           -
system          16.8M     max   deny           -
project.max-sem-ids
privileged        256       -   deny           -
system          16.8M     max   deny           -
project.max-crypto-memory
privileged       498MB      -   deny           -
system          16.0EB    max   deny           -
project.max-tasks
system          2.15G     max   deny           -
project.max-lwps
system          2.15G     max   deny           -
project.cpu-shares
privileged          1       -   none           -
system          65.5K     max   none           -
zone.max-lwps
system          2.15G     max   deny           -
zone.cpu-shares

  1. No comments yet.
  1. No trackbacks yet.