Performance Issues

Processes Attached to the root Lnode

For reasons of system management, processes attached to the root lnode are given almost all the CPU resources they demand. Therefore, if a CPU-bound process is attached to the root lnode, it will tie up a CPU, causing processes on other lnodes to slow or stop.

The following precautions can be taken to prevent this from occurring:

• The administrator should always log in to an lnode created for normal use by the administrator, rather than attaching to the root lnode. If there is a need to attach to the root lnode, be careful not to use any CPU-intensive applications, such as compilers. To use a UID of superuser without attaching to the root lnode, the administrator can use the su(1) command.

• The init.d scripts can be changed to use the srmuser program to attach all daemons to lnodes of their own, so they are not attached (by inheritance) to the root lnode. However, this solution cannot be routinely recommended. It can be a burden since a large number of files need to be edited, and the practice could inhibit the ability to integrate patches into a system later. A resolution that does not require this task to be performed manually is under investigation.

  For Solaris Resource Manager releases after 1.0, the scripts sbin_rc2 and sbin_rc3 provided in the /usr/srm/unsupport directory can be used to partially solve this problem.

A program that runs as setuid-root does not automatically attach to the root lnode. Normally, the process remains attached to the lnode of the parent that created it, and only the effective UID is changed.

CPU Resources Not Controlled by Solaris Resource Manager

Solaris Resource Manager only controls CPU use by processes in the SHR scheduling class. If excessive demands are made at higher priority by other scheduling classes, especially real-time (RT) and system (SYS), then SHR can only schedule with the residual CPU resource.

The use of the RT class conflicts with the Solaris Resource Manager software's ability to control the system. Real-time processes get complete access to the system, specifically so they can deliver real-time response (generally on the order of a few hundred microseconds). Processes running in the SHR class by definition have lower priority than anything running in real time, and Solaris Resource Manager has no control over RT processes. Real-time processes can easily consume all available resources, leaving Solaris Resource Manager nothing left to allocate to remaining processes.

One notable system service that runs entirely in the SYS class is the NFS server. Solaris Resource Manager cannot control the NFS daemons, because they run in SYS. The Solaris Resource Manager product's ability to allocate processor resources may be reduced on systems offering extensive NFS service.

While processes are executing kernel code (inside a system call), the usual time-slice preemption rules do not apply. Most system calls will only do a reasonable amount of work before they reach a preemption point. However, if the system is under high load from more intensive system calls, this can result in reduced overall responsiveness and is outside the control of a scheduling class.

If the system is short of available real memory, then the resulting I/O bottleneck as the page fault rate increases and process swapping increases leads to increased kernel consumption of CPU. Large amounts of time spent waiting on I/O may indicate lost CPU capacity. Again, this is outside the scope of a scheduling class to control.

The SHR scheduling class is a time-sharing (TS) scheduler. It uses the same global priority range as the TS and the interactive (IA) schedulers. It is not appropriate to mix the use of SHR with TS and IA except during the transition of moving all processes into or out of the SHR class. System operation with a mix of processes in SHR and TS classes will result in reduced quality of scheduling behavior in both classes. For this reason, Solaris Resource Manager prevents non-root processes from moving themselves or others to the TS or IA classes. The RT class uses an alternate priority range and may be used with the SHR class in the same way as the TS and IA classes.

If processes run by superuser contain code that uses the priocntl(2) system call directly instead of using the setpriority(3C) library routine to adjust process priorities, then the target processes may be moved into another scheduling class (typically TS). The setpriority library routine code accounts for the fact that the priocntl interface to SHR is binary compatible with that of TS and thus avoids the problem. The -c option of ps(1) or the -d option of priocntl(1) can be used to display the scheduling class of processes.

The same difficulty arises with superuser privilege processes that explicitly use priocntl(2) to manage the scheduling class membership of processes.