The product documentation library is also available:
http://www.rs6000.ibm.com/resource/aix_resource/Pubs/index.html
WARNING: schedtune is in the samples directory because it is VMM-implementation dependent. The schedtune code that accompanies each release of AIX was tailored specifically to the VMM in that release. schedtune is not supported under SMIT, nor has it been tested with all possible combinations of parameters. Misuse of this command can cause performance degradation or operating system failure. If execution of schedtune causes a system to crash with flashing 888s, then the appropriate level of schedtune for that release of AIX needs to be installed.
It takes experience and know-how to set schedtune parameters properly. Therefore, it is highly recommended that schedtune values be set only after consulting the AIX Performance Team. Call your support center and ask for a performance analysis through consult line.
The scheduler's CPU penalty calculations are based on two parameters that can be set with schedtune: -r and -d.
The formula used by the scheduler to calculate the amount to be added to a process or thread's priority value as a penalty for recent CPU use is:
NOTE: The default value for r is 16.
The once-per-second recalculation of the recently used CPU value of each process or thread is:
NOTE: The default value for d is 16.
The recent CPU usage value is displayed as the C column in the ps command output. The maximum value of recent CPU usage is 120. View the current nice value (NI), priority (PRI) and CPU usage value (C) for user processes by running:
ps -el | more
Memory-load control is intended to smooth out infrequent peaks in load that might otherwise cause a system to thrash. It is not intended to act continuously in a configuration that has too little RAM to handle its normal workload.
Memory is considered overcommitted when the number of pages written to paging space in the last second, multiplied by the value of the -h parameter, is greater than the number of page steals in the last second. A process is suspended when memory is overcommitted and the number of repages that the process has accumulated in the last second, multiplied by the value of the -p parameter, is greater than the number of page faults that the process has accumulated in the last second. The term "repages" refers to the number of pages belonging to the process which were reclaimed and are soon after referenced again by the process.
No notion of interactive versus non-interactive processes exists, so suspended processes may well be those that interact directly with end-users.
Do not change the memory-load control parameter settings unless your workload is consistent and the default parameters are not appropriate for your workload.
Here are all of the parameters available:
Purpose: Sets the system-wide criteria used to determine when process suspension begins and ends (system is thrashing).
Default: 0 (zero), if a system has 128MB or more of RAM; otherwise, it is 6.
For example:
schedtune -h 0
This use of the command will turn off memory-load control.
Purpose: Sets the per-process criterion used to determine which processes to suspend.
Default: 4
For example:
schedtune -p 2
This use of the command requires a higher level of repaging by a given
process before it is a candidate for suspension by
memory-load control.
Purpose: Sets the minimum number of processes that are exempt from suspension. This number is in addition to kernel processes, processes with fixed priority less than 60, processes with pinned memory, or processes awaiting events.
Default: 2
While m=2 is appropriate for a desktop, single-user configuration, it is frequently too small for larger multiuser or server configurations with large amounts of RAM. On those systems, increasing the value of m may result in better performance.
schedtune -m 10
This use of the command requires that the memory-load control always have at
least 10 user processes running when it is suspending
processes.
Purpose: Sets the number of seconds to wait after thrashing ends before making suspended processes able to be run.
Default: 1
schedtune -w 2
This use of the command would allow processes to be added back after two seconds
based, first, on their priority and, second, on the
length of their suspension period.
Purpose: Sets the number of seconds that a recently resumed process, which was previously suspended, is exempt from suspension.
Default: 2
Purpose: Sets the number of clock ticks to wait before retrying a failed fork call. The system will retry a failed fork call five times. For example, if a fork() subroutine call fails because there is not enough paging space available to create a new process, the system retries the call after waiting the specified number of clock ticks.
Default: 10
Purpose: Sets the short-term CPU usage decay rate. The valid values are 0 to 32. The default is to decay short term CPU usage by 1/2 (16/32) every second. Decreasing this value enables foreground processes to avoid competition with background processes for a longer time.
Default: 16
schedtune -r 6 -d 16
If a background process were started with nice -20, it
would be at least one second before the background
process began to receive any CPU time. Foreground
processes, however, would still be distinguishable on
the basis of CPU usage. Long-running foreground
processes that should probably be in the background would
ultimately accumulate enough CPU usage to keep them from
interfering with the true foreground. For example:
schedtune -r 32 -d 32
Long-running processes would reach a C value of 120 and
stay there, contending on the basis of their nice
values. New processes would have priority, regardless of
their nice value, until they had accumulated enough time
slices to bring them within the priority value range of
the existing processes.
Purpose: Set the weighting factor for short term CPU usage in priority calculations.
Default: 16
The valid values are 0 to 32. The default is to include 1/2 (16/32) of the short term CPU usage in the priority calculation. Decreasing this value makes it easier for foreground processes to compete. For example:
schedtune -r 0
With this use of the command, the CPU penalty is always 0,
making priority absolute. No background process would
get any CPU time unless there were no dispatchable
foreground processes at all. The priority values of the
processes would effectively be constant, although they
would not technically be fixed-priority processes. For
example:
schedtune -r 2
This use of the command ensures that any new foreground process would
receive at least 0.5 seconds of CPU time before it had to
compete with any process with a nice value equal to or
greater than 24.
Purpose: Sets the number of clock interrupts that must occur before the dispatcher is called. The CPU time slice is the period between recalculations of the priority value. Normally, recalculation is done at each tick (10 milliseconds) of the system clock. The number of clock ticks between recalculations (length of the time slice) can be increased by increments of 10 milliseconds (one clock tick).
However, the time slice is not a guaranteed amount of processor time. It is the longest time that a process or thread can be in control before it is replaced by another process or thread. A process or thread can lose control of the CPU before its full time slice when one of the following occurs:
It has been found that different values of t have not caused significant changes in the execution times of processes or threads.
This parameter only applies to threads with the SCHED_RR scheduling policy.
If the workload consists almost entirely of very long-running, CPU-intensive programs, increasing this parameter may have some positive effect.
Purpose: Restores ALL of the default values.
The current values are displayed when schedtune is executed without any parameters. Changes to the values go into effect immediately but do not exist after rebooting. If a permanent parameter change is needed, an appropriate entry should be put in one of the scripts called by /etc/inittab or an inittab entry created for schedtune itself. For example, an appropriate /etc/inittab line for raising the minimum level of multiprogramming to five is:
schedtune:2:wait:/usr/samples/kernel/schedtune -m 5
[ Doc Ref: 90605221814622 Publish Date: Spt. 29, 2000 4FAX Ref: 3239 ]