When migrating to Solaris 10, most people focus on the more obvious changes, such as using SMF to manage services, and ZFS for the filesystems. Something that seems to catch lots by surprise is what happened to kernel turnables in Solaris 10.
In Solaris, the kernel is largely self-tuning, with each new major release and kernel patch building on this. There’s not really that much to tweak, and for most of the time, you can just leave Solaris to get on with it.
There are always edge cases, though. Oracle is a classic one, and if you’re doing HPC, big compute jobs, or lots of I/O intensive work, you’ll want to start tweaking.
In previous releases of Solaris, this involved digging out the correct syntax from the Solaris documentation, working out what the values should be, then editing /etc/system, followed by a reboot.
Oracle DBAs in particular will now be distressed to note that Solaris 10 happily ignores the settings in /etc/system. If you’re lucky, you’ll see some complaints about deprecated settings in /var/adm/messages.
Lots of the defaults have now been changed in Solaris 10, and they’re a lot more sensible – you shouldn’t really need to play with System V IPC tunables like semaphores and message queues.
The Solaris 10 Tunable Parameters Reference Manual can be found at http://download.oracle.com/docs/cd/E19253-01/817-0404/
Things have changed a bit for Oracle databases as well, which is the most common case for kernel tuning most people will encounter. Solaris Resource Controls – aka projects – are now used to set things up for Oracle.
Setting up a project for Oracle, and then defining the kernel settings, is pretty straightforward:
- Setup a new project for the Oracle user:
- Modify the project to increase the number of semaphores:
projmod -s -K “process.max-sem-nsems=VALUE” ‘user.oracle’
Where VALUE should be the total number of Oracle processes, + 10. Chris Gerhard has an excellent blog entry here that discusses the pros and cons of fiddling with the number of semaphores.
- Modify the project to set the maximum shared memory segment size:
projmod -s -K “project.max-shm-memory=(privileged,VALUE,deny)” ‘user.oracle’
This corresponds to the old shmsys:shminfo_shmmax kernel tunable in /etc/system.
Once you’ve done that, you’re all set. The old semsys:seminfo_semmns tunable is now deprecated, and you should find that the resource controls that replaced the old tunables semsys:seminfo_semopm and shmsys:msginfo_msgmni have high enough defaults that you won’t need to tweak them.
There are still lots of Solaris 8 and Solaris 9 machines out there, that are only just coming to the end of their service life. Although Solaris 10 has been out for a while, and we’re looking at Solaris 11 being released soon, many clients are still looking to tackle the challenges that a Solaris 10 migration brings.