Global Solaris Resource Manager Parameters via srmadm

The srmadm command allows an administrator to set, modify, or display the global Solaris Resource Manager parameters. Refer to the srmadm(1MSRM) man page for details of all parameters.

The srmadm command can be called any number of times to set various parameters. It is not necessary to include all settings on a single invocation. This also means that srmadm can be used to change the operational parameters of a running Solaris Resource Manager system on the fly, although some caution should be taken.

Of particular importance to administrators are the srmadm options that enable or disable the main features of Solaris Resource Manager. These are:

fileopen[={y|n}]

The default database is /var/srm/srmDB; it can be overridden with the -f option. Note that closing the Solaris Resource Manager database file in mid-operation should be regarded as an emergency action. It has several undesirable consequences: all processes will continue running on the surrogate root lnode, which may give them more privilege than normal; the SHR scheduler is disabled; and Solaris Resource Manager limit enforcement ceases. When disabled, Solaris Resource Manager has no limits database open, and its cache contains only the surrogate root lnode to which all processes are attached.

share[={y|n}]

When enabled, the Solaris Resource Manager SHR scheduler is used and CPU scheduling takes place according to the Solaris Resource Manager dynamic usage and decay algorithm. This mode cannot be set unless fileopen mode is enabled. When disabled, the SHR scheduler's usage calculations are frozen, and processes are scheduled "round-robin" with fixed equal priorities.

limits[={y|n}]

When enabled, Solaris Resource Manager enforces the virtual memory and process limits. This mode cannot be set unless fileopen mode is enabled. When disabled, Solaris Resource Manager will keep usage attributes up to date, but will not enforce limits.

adjgroups[={y|n}]

When enabled, the Solaris Resource Manager SHR scheduler's global group effective share adjustment is used. The enabled state is recommended in most circumstances. Every run interval, the normalized usages of all limits entries are recalculated. If the adjgroups scheduling mode is enabled, then extra processing of normalized usages is performed as follows. The scheduler makes a pass over the scheduling tree, comparing each group's recently received effective share with its entitlement. Groups that have received less than their group entitlement are biased to receive a greater effective share in the next run interval. This ensures that groups receive their entitlements of CPU service whenever possible, regardless of the actions of their members.

limshare[={y|n}]

When enabled, the SHR scheduler applies its priority ceiling feature to limit all users' effective shares, which prevents extremely low-usage users from briefly acquiring almost 100 percent of CPU. The enabled state is recommended.

The rate of CPU service for a user is roughly inversely proportional to the user's usage. If not active for a long time, a user's usage decays to near-zero. When such a user logs in (or the lnode becomes active in any way), then for the duration of the next run interval, the user's processes could have such high priority that they monopolize the CPU.

Enabling the limshare scheduling flag causes the scheduler to estimate the effective share that an lnode will receive before the next run interval. If the result exceeds the user's assigned entitlement by a given factor (see maxushare), the user's normalized usage is readjusted to prevent this.

There are two optional parameters to srmadm that are also useful to an administrator:

• The -v parameter prints a formatted report of all current parameter settings on standard output. Supplying more -v parameters (-V 1, -V 2, and -V 3) results in a more verbose report. Invoking srmadm with no arguments is equivalent to supplying a single -v option.

• The -d parameter initializes the Solaris Resource Manager system structure with default values instead of reading the current kernel settings. The default values, which mainly give control over scheduling behavior, are built into srmadm and provide a good starting point from which to customize Solaris Resource Manager. The kernel begins with the same values preset.

The following examples illustrate typical srmadm commands.

To turn on Solaris Resource Manager, enabling the SHR scheduler and resource limits:

# srmadm set -f /var/srm/srmDB fileopen=y:share=y:limits=y 

To set the CPU usage decay rate to have a half-life of 5 minutes:

# srmadm set usagedecay=300s 

To display the current flag settings and charges:

% srmadm 

To show all the default settings:

% srmadm show -dv 

Disabling Solaris Resource Manager

The srmadm(1MSRM) command can disable Solaris Resource Manager by clearing the fileopen flag: all processes are moved onto the surrogate root lnode, other changed lnodes in the cache are flushed to disk, and the limits database is closed. This automatically forces the share and limits flags off, disabling the SHR scheduler and limit enforcement, respectively. The share and limits flags may be turned off independently if required while leaving the limits database open. This is better than closing the file, because processes can stay attached to their correct lnodes.

Note that if the Solaris Resource Manager scheduler alone is disabled in mid-operation, all this does is suspend the usage and decay algorithm. The scheduler still continues handling processes in the SHR scheduling class, but as each is assigned an updated priority, the same value is used, resulting in simple "round-robin" scheduling.

Re-enabling Solaris Resource Manager by opening the file and setting the share and/or limits flags after the file has been closed will not cause existing processes to move off the root lnode. It is best not to close the Solaris Resource Manager database during normal operation. If it is closed, the system should be rebooted in order to ensure correct attachment of processes to lnodes.