This stuff can really be bad for you when we come hunting you down for messing up the kernel.

Tuning /etc/system

"UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." -- Doug Gwyn

In Solaris 2.x, there is no need to rebuild the kernel after changing some kernel parameters. Here are some commonly encountered tuning problems and how to fix them. For more details, read the man pages and/or answerbook.

In Solaris 2.3 there is more info in the Tuning Kernel Parameters section. Sun simply hasn't gotten around to documenting all of it. The kernel still sees many, many changes every release and keeping the documentation in sync with that is a daunting task. Some of the knobs in the kernel are not documented on purpose, I think. Just as people start punching random button and turing random knobs when they can't get a machine to work, they'll start to switch on/off all kinds of stuff in the kernel giving only half a chance..

• How to increase the number of Pseudo Terminal Sevices
• How to change maxusers
• How to change resource limits
• How to change max file descriptors limit
• System V shared memory/semaphores messages.
• Increasing the size of the buffer pool for storing SysV messages

The name of some basic parameters that are defined in /etc/system.

One of the most commonly asked parameters:

set pt_cnt = <n>       * number of SysV ptys

Personnaly recommended:

(for Solaris 2.3, 2.4)

set nfs:nfs_portmon  = 1 * for increased fileserver security.

(for Solaris 2.5 and above) 

 set nfssrv:nfs_portmon = 1  * for increased fileserver security.

Run crash and have a look at the output of the var command; there is a structure v in your kernel that holds all the tunable parameters. The definition is in /usr/include/sys/var.h And there is another structure rlimits which lists the resource limits; see the definition in /usr/include/sys/resource.h BTW: I do not know of a "clean" way to change these values yet. It seems to be impossible to set a field of a structure using /etc/system. All I can do so far is patching the kerning with adb.

1. The kernel is configured automagically by doing a 'boot -r'. This should take care of the necessary drivers, adjusts the tunable parameters. The first part seems to be OK. It does what it should, if for any reason you don't want to load a driver (but you HAVE the hardware), you can easily figure out what to do: the /usr/sbin/modinfo -i should tell you what drivers are loaded. You can play with the modunload command to figure out if you can really remove it. The second part (tunable parameters)are not so clean.

2. You can get the names of these parameters using the nm on /kernel/unix. After grepping for OBJT and GLOB, I ended up with more than 1000 names. Some of them are obvious (like maxusers), but I guess at least 95% is not very interesting. So this is not the way. The claim by Sun that the automatic kernel configuration does what it should is just not true. There are some built in thumb of rules but that's all. I recall VMS 4.7 (at least 5 years old): it was able to collect information and adjust the parameters according to the usage. The Solaris system is not capable of doing this yet.

3. I was playing with sar. To use this, you can do many things, but the answerbook suggested way is pretty easy: become sys (su sys) and edit the crontab file. The entries are already there so it should be easy. Than wait a few days to collect info. To examine the collected info, do a sar -A | more. This will report EVERY collected info for the current day (do a man sar to figure out how to get the previous days). The report makes sense, i.e. the statistics are reported in groups so you don't need a 2000 char long display. Here you might catch what is the source of your problems.

4. Well, you are pretty close. Go to 2.) and try to figure out which parameter should be adjusted. Sometimes it's easy, sometimes it's nearly hopeless.

5. Check out the current setting. Start adb:

    adb -k /dev/ksyms /dev/mem
   
   (You don't get a prompt). To check a parameter
   (e.g. maxusers):
   
   maxusers/D
   maxusers/X
   
   

   The first gives the decimal, the second the hex value. Depending on the variable, you might need different commands (do a man adb).

6. Guess the correct value. Put it into /etc/system. The file is self descriptive, e.g. to increase the maxusers, insert:

                   set maxusers=16
   

   You can also disable the loading of modules here. After you are done, you have to do a halt and a 'boot -r' (the touch /reconfigure seems to be broken in some cases), than a reboot (I'm not quite sure if this is needed but since you already restarted the machine, an additional restart should not hurt).

   Still needed: what are the useful kernel parameters? The maxusers is obviously one of them, while

   s_cache_flushpagectx
   

   probably is not.
   

Changing the maxusers on the system

Guess the correct value. Put it into /etc/system. The file is self descriptive, e.g. to increase the maxusers, insert:

                set maxusers=16

You can also disable the loading of modules here. After you are done, you have to do a halt and a 'boot -r' (the touch /reconfigure seems to be broken in some cases), than a reboot (I'm not quite sure if this is needed but since you already restarted the machine, an additional restart should not hurt).

Increasing the default pts device number

In /etc/system:

        set pt_cnt = <number>

# touch /reconfigure
# reboot

Maximum number of processes per user and other resources

The maximum number of processes per user is maxuprc. The default value for maxuprc is all processes (-5), which is fine for desktop machines but not for large ``mainframe'' type machines. And multi-user student machines. (Runaway forks are very common).

To change this value, set set maxuprc = <number>

Well, it works in Solaris 2.3, I tried the canonical runaway fork program: "while(1) fork()" and that user did stop at the correct number of PIDs. Of course that I have to do a reboot to stop that processes, but the important is that a single user can't hang the system anymore.

Increasing the maximum number of file descriptors per process

To get more info use the sysdef -i .


(...)
* Process Resource Limit Tunables (Current:Maximum)
*
Infinity:Infinity   cpu time
Infinity:Infinity   file size
7ffff000:7ffff000   heap size
  800000:7ffff000   stack size
Infinity:Infinity   core file size
      40:     400   file descriptors     <-------------
Infinity:Infinity   mapped memory
(...)

To increase the default number of file descriptors per process, rlimits+28 must be patched with adb as shown below.

Warning- using adb to patch the kernel is dangerous. Mistyping a command could crash the system or render it unbootable. Save an unpatched kernel copy and do not increase the hard limits.

#cp /kernel/unix /kernel/unix.orig
#adb -k -w /kernel/unix /dev/mem
rlimits,e?X
rlimits:
rlimits:        7fffffff        7fffffff        7fffffff        7fffffff
                7ffff000        7ffff000        800000          7ffff000
                7fffffff        7fffffff        40              400
                7fffffff        7fffffff
rlimits+28?W80
rlimits+28/W80
rlimits,e?X
rlimits:
rlimits:        7fffffff        7fffffff        7fffffff        7fffffff
                7ffff000        7ffff000        800000          7ffff000
                7fffffff        7fffffff        80              400
                7fffffff        7fffffff

$q
#

It's never as easy as you think

SYSV shared memory, semaphores and messages

The following will work for a small oracle type system

In /etc/system

set shmsys:shminfo_shmmax=16000000
set shmsys:shminfo_shmmin=1
set shmsys:shminfo_shmmni=100
set shmsys:shminfo_shmseg=20
set semsys:seminfo_semmns=400
set semsys:seminfo_semmni=140
set semsys:seminfo_semmsl=60