autoup
| Description | Along with tune_t_flushr, autoup controls the amount of
memory examined for dirty pages in each invocation and frequency of file system
sync operations.
The value of autoup is also used to control whether
a buffer is written out from the free list. Buffers marked with the B_DELWRI flag (file content pages that have changed) are written
out whenever the buffer has been on the list for longer than autoup seconds. Increasing the value of autoup
keeps the buffers around for a longer time in memory.
| | Data Type | Signed integer
| | Default | 30
| | Range | 1 to MAXINT
| | Units | Seconds
| | Dynamic? | No
| | Validation | If autoup
is less than or equal to zero, it is reset to 30 and a warning message is
displayed. This check is only done at boot time.
| | Implicit | autoup
should be an integer multiple of tune_t_fsflushr. At a
minimum, autoup should be at least 6 times tune_t_fsflushr. If not, excessive amounts of memory will be scanned each time fsflush is invoked.
(total system pages x tune_t_fsflushr) should be
greater than or equal to autoup to cause memory to be checked
if dopageflush is non-zero.
| | When to Change | There are several
potential situations for changing autoup and or tune_t_fsflushr:
Systems with large amounts of memory--In this case, increasing autoup reduces the amount of memory scanned in each invocation
of fsflush.
Systems with minimal memory demand--Increasing both autoup
and tune_t_fsflushr reduces the number of scans made. autoup should be increased also to maintain the current ratio of autoup / tune_t_fsflushr.
Systems with large numbers of transient files (for example,
mail servers or software build machines)--If large numbers of files are
created and then deleted, fsflush might unnecessarily write
data pages for those files to disk.
| | Commitment Level | Unstable
|
dopageflush
| Description | Controls whether memory
is examined for modified pages during fsflush invocations.
In each invocation of fsflush, the number of memory pages
in the system is determined (it might have changed because of a dynamic reconfiguration
operation). Each invocation scans (total number of pages x tune_t_fsflushr) / autoup pages.
| | Data Type | Signed integer
| | Default | 1 (enabled)
| | Range | 0 (disabled) or 1 (enabled)
| | Units | Toggle (on/off)
| | Dynamic? | Yes
| | Validation | None
| | When to Change | If the system page
scanner rarely runs, indicated by a value of 0 in the sr
column of vmstat output.
| | Commitment Level | Unstable
|
doiflush
| Description | Controls whether file
system metadata syncs will be executed during fsflush invocations.
Syncs are done every Nth invocation of fsflush where N= (autoup / tune_t_fsflushr). Because this is an integer division, if tune_t_fsflushr is greater than autoup, a sync will be done
on every invocation of fsflush because the code checks
to see if its iteration counter is greater than or equal to N. Note that N is computed once on
invocation of fsflush. Later changes to tune_t_fsflushr or autoup will have no effect on the frequency
of sync operations.
| | Data Type | Signed integer
| | Default | 1 (enabled)
| | Range | 0 (disabled) or 1 (enabled)
| | Units | Toggle (on/off)
| | Dynamic? | Yes
| | Validation | None
| | When to Change | When files are frequently
modified over a period of time and the load caused by the flushing perturbs
system behavior. Files whose existence, and therefore consistency of state
does not matter if the system reboots, are better kept in a TMPFS file system
(for example, /tmp). Inode traffic can be reduced on
systems running the Solaris 7, 8, or 9 releases by using the mount -noatime option. This option eliminates inode updates
when the file is accessed.
A system engaged in realtime processing might want to disable this option
and use explicit application file syncing to achieve consistency.
| | Commitment Level | Unstable
|
Process Sizing Tunables
Several variables are used to control the number of processes that are
available on the system and the number of processes that an individual user
can create. The foundation variable is maxusers, which
drives the values assigned to max_nprocs and maxuprc.
maxusers
| Description | Originally, maxusers defined the number of logged in users the system could
support. Various tables were sized based on this setting when a kernel was
generated. Now, the Solaris release does much of its sizing based on the amount
of memory on the system, so much of the past use of maxusers
has changed. There are still a number of subsystems that are derived from maxusers:
The maximum number of processes on the system
The number of quota structures held in the system
The size of the directory name lookup cache (DNLC)
| | Data Type | Signed integer
| | Default | Lesser of the amount of
memory in Mbytes and 2048
| | Range | 1 to 2048, based on physical
memory if not set in the /etc/system file.
1 to 4096, if set in the /etc/system file.
| | Units | Users
| | Dynamic? | No. After computation of
dependent variables is done, maxusers is never referenced
again.
| | Validation | None
| | When to Change | When the default
number of user processes derived by the system is too low. This situation
is seen by the following message that displays on the system console:
When the default number of processes is too high:
Database servers that have a lot of memory and relatively
few running processes, can save system memory by reducing the default value
of maxusers.
File servers that have a lot of memory and few running processes
can reduce this value, but should explicitly set the size of the DNLC. (See ncsize.)
Compute servers that have a lot of memory and few running
processes can reduce this value.
| | Commitment Level | Unstable
| | Change History | For information,
see maxusers (Solaris 7 Release).
|
|
Previous