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 users .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 its 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 users 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