Softpanorama
(slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Google   

AIX performance tuning

News

See also

 Redbooks IBM Links Recommended Links Recommended Papers FAQs Hardening Security
Man pages Reference Log administration Classic unix Tools

Patches

Open source software for AIX

      
ps top vmstat nfsstat nice sar Tips Humor Etc
Notes:
  • This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Some amount of grammar and spelling errors should be expected.
  • The site contain some broken links as it develops like a living tree... Please try to use Google, Open directory, etc. to find a replacement link (see HOWTO search the WEB for details). We would appreciate if you can mail us a correct link.
Google Search
Open directory
Research Index

Old News ;-)

[Nov 14, 2008] Database Performance Tuning on AIX by Budi Darmawan; Gary Groenewald; Allan Irving; Sergio Henrique Soares Monteiro; Keirnan M. Snedeker

January 20, 2003

Publisher: IBM Redbooks

[PDF] Database Performance Tuning on AIX

[Nov 11, 2008] Tuning Tips (from Webshere Express manula)

Change the following configuration settings or variables according to your needs:

Results

This tuning procedure improves performance of WebSphere Application Server on the AIX operating system.

What to do next

After tuning your operating system for performance, consult the other tuning topics for various tuning tips.

[Nov 6, 2007] nmon performance A free tool to analyze AIX and Linux performance

Free tool

Introduction

The nmon tool is designed for AIX and Linux performance specialists to use for monitoring and analyzing performance data, including:

 

Also included is a new tool to generate graphs from the nmon output and create .gif files that can be displayed on a Web site.

See the README file for more details.

Benefits of the tool

The nmon tool is helpful in presenting all the important performance tuning information on one screen and dynamically updating it. This efficient tool works on any dumb screen, telnet session, or even a dial-up line. In addition, it does not consume many CPU cycles, usually below two percent. On newer machines, CPU usage is well below one percent.

Data is displayed on the screen and updated once every two seconds, using a dumb screen. However, you can easily change this interval to a longer or shorter time period. If you stretch the window and display the data on X Windows, VNC, PuTTY, or similar, the nmon tool can output a great deal of information in one place.

The nmon tool can also capture the same data to a text file for later analysis and graphing for reports. The output is in a spreadsheet format (.csv).

[Nov 6, 2007] Some useful perfomance optimization artciles

[Jun 14, 2007]  Performance tuning UNIX systems

Be nice to your computers and examine some general guidelines for tuning server performance. A computer is like an employee who does tasks for you -- it's a good idea to keep from overburdening them. One way to keep this from happening is to carefully tune the processes that run on it. This article provides some simple performance tuning steps using the UNIX nice commands.

[Jun 11, 2007]  System Administration Toolkit: Monitoring a slow system

When your UNIX(R) system runs slow, it is vital that you discover what the problem is as quickly as possible so you can get your system back into the normal operating mode. There are many causes for a slow system, but actually identifying the problem can be exceedingly difficult. In this article, study examples of how to identify and diagnose the cause of your slow running UNIX system to get your machine running properly again.

[Jun 11, 2007]  IBM Redbooks AIX 5L Practical Performance Tools and Tuning Guide

This IBM Redbook incorporates the latest AIX 5L performance and tuning tools. It is a comprehensive guide about the performance monitoring and tuning tools that are provided with AIX 5L Version 5.3, and it is the ultimate guide for system administrators and support professionals who want to efficiently use the AIX performance monitoring and tuning tools and understand how to interpret the statistics.

The usage of each tool is explained along with the measurements it takes and the statistics it produces. This redbook contains a large number of usage and output examples for each of the tools, pointing out the relevant statistics to look for when analyzing an AIX system's performance from a practical point of view. It also explains the performance API available with AIX 5L and gives examples about how to create your own performance tools.

This redbook also contains an overview of the graphical AIX performance tools available with AIX 5L and the AIX Performance Toolbox Version 3.0.

This redbook is a rework of the very popular redbook AIX 5L Performance Tools Handbook, SG24-6039, published in 2003.

[Jun 11, 2007] IBM Wikis - AIX 5L Wiki - nmon Manual

nmon is a free performance monitoring tool for AIX and Linux and is downloadable from this Wiki.
This Wiki is the sole place to get nmon.
nmon now includes other tools like

There is also a free spreadsheet analyser for nmon captured data from Stephen Atkins from

This nmon tool gives you a huge amount of information on one screen and can save data to a comma separated values (.csv) file for latest analyses. This tool runs on:

Once you have proved these versions are OK, all previous versions of nmon should be deleted.

[Jun 11, 2007] nmon performance: A free tool to analyze AIX and Linux performance

Usage notes: This nmon tool is NOT OFFICIALLY SUPPORTED. No warrantee is given or implied, and you cannot obtain help with it from IBM. If you have a question on nmon, please go on the Performance Tools Forum site (see Resources) so that others can find and benefit from the answers. To protect your email address from junk mail, you need to create a USER ID first (takes 20 seconds at most).

The nmon tool runs on:

 

The nmon tool is updated roughly every six months, or when new operating system releases are available. To place your name on the e-mail list for updates, contact Nigel Griffiths.

Use this tool together with nmon analyser (see Resources), which loads the nmon output file and automatically creates dozens of graphs.

Introduction

The nmon tool is designed for AIX and Linux performance specialists to use for monitoring and analyzing performance data, including:

Also included is a new tool to generate graphs from the nmon output and create .gif files that can be displayed on a Web site.

See the README file for more details.

[Jun 11, 2007] IBM Wikis - AIX 5L Wiki - nmonanalyser

Usage notes: The nmon_analyser tool is NOT OFFICIALLY SUPPORTED. No warrantee is given or implied, and you cannot obtain help with it from IBM.

The tool currently comes in the form of a spreadsheet for use with Microsoft® Excel™ 2000 or later.

The nmon_analyser tool is designed to work with the latest version of nmon, but it is also tested with older versions for backwards compatibility. The tool is updated whenever nmon is updated, and at irregular intervals for new function. To place your name on the e-mail list for updates, contact Stephen Atkins.

Benefits of the tool

The nmon_analyser tool is helpful in analyzing performance data captured using the nmon performance tool. It allows a performance specialist to:

The tool also automatically produces graphs for each major section of output.

In addition, the tool performs analyses of the nmon data to produce:

ftp://ftp.software.ibm.com/aix/tools/perftools/perfpmr

[May 15, 2007] Optimizing AIX 5L performance: Monitoring your CPU, Part 3 by Ken Milberg

The article discusses controlling thread usage and CPU binding.  Great list of  resources at the end

This three-part series focuses on the various aspects of Central Processing Unit (CPU) performance and monitoring. The first installment of the series provides an overview of how to efficiently monitor your CPU, discusses the methodology for performance tuning, and gives considerations that can impact performance, either positively or negatively. Though the first part of the series goes through some commands, the second installment focuses much more on the detail of actual CPU systems monitoring and analyzing trends and results. The third installment focuses on proactively controlling thread usage and other ways to tune your CPU to maximize performance. Throughout this series, I'll also expound on various best practices of AIX® CPU performance tuning and monitoring.

Introduction

This article covers threads, processes, and CPU binding. It also discusses how to use several of the tools illustrated in prior installments to make changes to your systems. The most important commands used to tune the CPU scheduler and the various methods of binding threads that are available on AIX Version 5.3 are also covered.

A junior administrator might consider process management nothing more than monitoring active processes and possibly killing runaway or zombie processes. You'll find out that there is a lot more to process management than using the kill command, or even nice. The fundamental question that needs to be answered before moving forward is how processes relate to threads. The answer is surprisingly simply. The process is the actual entity that AIX uses to control the use of system resources, while the threads control the actual time consumption, as each kernel thread is a single sequential flow of control. Each process is made up of one or more threads. Controlling thread usage is where you can make a difference. To do this, you need to understand the tools that allow you to work with threads to improve your CPU performance, which is the scope of this final part of the series.

Thread monitoring

In this section, I discuss the tools and commands that are available to help you monitor and analyze thread usage. While AIX Version 4 introduced the usage of threads to control processor time consumption, it was in AIX 5L™ where system management tools really evolved to help you monitor and analyze the thread usage. One such tool is procmon, which was introduced in AIX Version 5.3.

Procmon displays a list of processes (changing dynamically while your system changes) that enable you to gather information about what is running on your system. Where it really stands out compared to other monitoring tools is that it actually allows you to run commands to facilitate process and thread management. Some of the critical information that it gathers with respect to performance tuning includes:

You can even kill jobs and renice them on the fly. Figure 1 gives a nice graphical representation of overall performance. To launch the Performance Workbench Platform, use: # perfwb.

... ... ...

Summary

In this article, I've discussed the importance of controlling thread usage and CPU binding. You've looked at the key tools and utilities used to analyze threads and administrate your processes. Further, you've tuned your kernel using schedo, learned all about processor affinity, and figured out how to bind CPUs. This three-part series on CPU monitoring first introduced the overall concepts of tuning, then went into monitoring and data collection, and concluded with systems tuning and administration. While most of you might be more familiar with tuning memory subsystems, I hope this series illustrated the importance of CPU monitoring and tuning.

This topic contains links to information about managing and tuning the performance of your AIX system.

Values for minperm and maxperm parameters

The operating system takes advantage of the varying requirements for real memory by leaving in memory pages of files that have been read or written.

If the file pages are requested again before their page frames are reassigned, this technique saves an I/O operation. These file pages may be from local or remote (for example, NFS) file systems.

The ratio of page frames used for files versus those used for computational (working or program text) segments is loosely controlled by the minperm and maxperm values:

  • If percentage of RAM occupied by file pages rises above maxperm, page-replacement steals only file pages.
  • If percentage of RAM occupied by file pages falls below minperm, page-replacement steals both file and computational pages.
  • If percentage of RAM occupied by file pages is between minperm and maxperm, page-replacement steals only file pages unless the number of file repages is higher than the number of computational repages.
In a particular workload, it might be worthwhile to emphasize the avoidance of file I/O. In another workload, keeping computational segment pages in memory might be more important. To understand what the ratio is in the untuned state, use the vmstat command with the -v option. 
# vmstat -v
 1048576 memory pages 
 1002054 lruable pages 
 478136 free pages 
 1 memory pools 
 95342 pinned pages 
 80.1 maxpin percentage 
 20.0 minperm percentage 
 80.0 maxperm percentage 
 36.1 numperm percentage 
 362570 file pages 
 0.0 compressed percentage 
 0 compressed pages 
 35.0 numclient percentage 
 80.0 maxclient percentage 
 350782 client pages 
 0 remote pageouts scheduled 
 80 pending disk I/Os blocked with no pbuf 
 0 paging space I/Os blocked with no psbuf 
 3312 filesystem I/Os blocked with no fsbuf 
 0 client filesystem I/Os blocked with no fsbuf 
 474178 external pager filesystem I/Os blocked with no fsbuf

The numperm value gives the number of file pages in memory, 362570. This is 36.1 percent of real memory.

If you notice that the system is paging out to paging space, it could be that the file repaging rate is higher than the computational repaging rate since the number of file pages in memory is below the maxperm value. So, in this case we can prevent computational pages from being paged out by lowering the maxperm value to something lower than the numperm value. Since the numperm value is approximately 36%, we could lower the maxperm value down to 30%. Therefore, the page replacement algorithm only steals file pages. If the lru_file_repage parameter is set to 0, only file pages are stolen if the number of file pages in memory is greater than the value of the minperm parameter.

Performance Management Guide - Controlling Contention for the CPU

AIX Version 4 introduced the use of threads to control processor time consumption, but most of the system management tools still refer to the process in which a thread is running, rather than the thread itself.

Controlling the Priority of User Processes

User-process priorities can be manipulated using the nice or renice command or the setpri() subroutine, and displayed with the ps command. An overview of priority is provided in Process and Thread Priority.

Priority calculation is employed to accomplish the following:

The degree to which the user priorities can be manipulated is release-dependent. The algorithm for calculating priority value in AIX 4.3.1 and prior releases is more limiting than the current algorithm. The algorithm was changed in AIX 4.3.2 so that user priorities can be manipulated more than in previous releases. There is improved distinction between foreground and background processes. Using a given nice value will have a greater effect on CPU utilization. See Priority Calculation.

Running a Command with the nice Command

Any user can run a command at a less-favorable-than-normal priority by using the nice command. Only the root user can use the nice command to run commands at a more-favorable-than-normal priority. In this case, the nice command values range between -20 and 19.

With the nice command, the user specifies a value to be added to or subtracted from the standard nice value. The modified nice value is used for the process that runs the specified command. The priority of the process is still non-fixed; that is, the priority value is still recalculated periodically based on the CPU usage, nice value, and minimum user-process-priority value.

The standard nice value of a foreground process is 20 (24 for a ksh background process). The following command would cause the vmstat command to be run in the foreground with a nice value of 25 (instead of the standard 20), resulting in a less favorable priority. 

# nice -n 5 vmstat 10 3 > vmstat.out

If you use the root login, the vmstat command can be run at a more favorable priority with the following: 

# nice -n -5 vmstat 10 3 > vmstat.out

If you were not using root login and issued the preceeding example nice command, the vmstat command would still be run but at the standard nice value of 20, and the nice command would not issue any error message.

Setting a Fixed Priority with the setpri Subroutine

An application that runs under the root user ID can use the setpri() subroutine to set its own priority or that of another process. For example: 

retcode = setpri(0,59);

would give the current process a fixed priority of 59. If the setpri() subroutine fails, it returns -1.

The following program accepts a priority value and a list of process IDs and sets the priority of all of the processes to the specified value. 

/*
 fixprocpri.c
 Usage: fixprocpri priority PID . . .
*/
 
#include <sys/sched.h>
#include <stdio.h>
#include <sys/errno.h>
 
main(int argc,char **argv)
{
 pid_t ProcessID;
 int Priority,ReturnP;
 
 if( argc < 3 ) {
 printf(" usage - setpri priority pid(s) \n");
 exit(1);
 }
 
 argv++;
 Priority=atoi(*argv++);
 if ( Priority < 50 ) {
 printf(" Priority must be >= 50 \n");
 exit(1);
 }
 
 while (*argv) {
 ProcessID=atoi(*argv++);
 ReturnP = setpri(ProcessID, Priority);
 if ( ReturnP > 0 )
 printf("pid=%d new pri=%d old pri=%d\n",
 (int)ProcessID,Priority,ReturnP);
 else {
 perror(" setpri failed ");
 exit(1);
 }
 }
}

Displaying Process Priority with the ps Command

The -l (lowercase L) flag of the ps command displays the nice values and current priority values of the specified processes. For example, you can display the priorities of all of the processes owned by a given user with the following: 

# ps -lu hoetzel
 F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
 241801 S 200 7032 7286 0 60 20 1b4c 108 pts/2 0:00 ksh
 200801 S 200 7568 7032 0 70 25 2310 88 5910a58 pts/2 0:00 vmstat
 241801 S 200 8544 6494 0 60 20 154b 108 pts/0 0:00 ksh

The output shows the result of the nice -n 5 command described previously. Process 7568 has an inferior priority of 70. (The ps command was run by a separate session in superuser mode, hence the presence of two TTYs.)

If one of the processes had used the setpri(10758, 59) subroutine to give itself a fixed priority, a sample ps -l output would be as follows: 

 F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
 200903 S 0 10758 10500 0 59 -- 3438 40 4f91f98 pts/0 0:00 fixpri

Modifying the Priority with the renice Command

The renice command alters the nice value, and thus the priority, of one or more processes that are already running. The processes are identified either by process ID, process group ID, or the name of the user who owns the processes.

For AIX Version 4, the syntax of the renice command has been changed to complement the alternative syntax of the nice command, which uses the -n flag to identify the nice-value increment.

The renice command cannot be used on fixed-priority processes. A non-root user can specify a value to be added to, but not subtracted from the nice value of one or more running processes. The modification is done to the nice values of the processes. The priority of these processes is still non-fixed. Only the root user can use the renice command to alter the priority value within the range of -20 to 20, or subtract from the nice value of one or more running processes.

To continue the example, use the renice command to alter the nice value of the vmstat process that you started with nice. 

# renice -n -5 7568
# ps -lu hoetzel
 F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
 241801 S 200 7032 7286 0 60 20 1b4c 108 pts/2 0:00 ksh
 200801 S 200 7568 7032 0 60 20 2310 92 5910a58 pts/2 0:00 vmstat
 241801 S 200 8544 6494 0 60 20 154b 108 pts/0 0:00 ksh

Now the process is running at a more favorable priority that is equal to the other foreground processes. To undo the effects of this, you could issue the following: 

# renice -n 5 7569
# ps -lu hoetzel
 F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
 241801 S 200 7032 7286 0 60 20 1b4c 108 pts/2 0:00 ksh
 200801 S 200 7568 7032 1 70 25 2310 92 5910a58 pts/2 0:00 vmstat
 241801 S 200 8544 6494 0 60 20 154b 108 pts/0 0:00 ksh

In these examples, the renice command was run by the root user. When run by an ordinary user ID, there are two major limitations to the use of the renice command:

Clarification of the nice and renice Command Syntax

The nice and renice commands have different ways of specifying the amount that is to be added to the standard nice value of 20.

For AIX Version 4, the syntax of the renice command has been changed to complement the alternative syntax of the nice command, which uses the -n flag to identify the nice-value increment.

Command Command Resulting nice Value Best Priority Value in AIX 4.3.1 Best Priority Value in AIX 4.3.2 and Subsequent Releases
nice -n 5 renice -n 5 25 65 70
nice -n +5 renice -n +5 25 65 70
nice -n -5 renice -n -5 15 55 55
Tuning the Thread-Priority-Value Calculation

This section discusses tuning using the following:

The schedtune command and several enhancements to the CPU scheduler permit changes to the parameters used to calculate the priority value for each thread. See Process and Thread Priority for background information on priority.

To determine whether the schedtune program is installed and available, run the following command: 

# lslpp -lI bos.adt.samples

Priority Calculation

The formula for calculating the priority value is: 

priority value = base priority + nice penalty + (CPU penalty based on recent CPU usage)

The recent CPU usage value of a given thread is incremented by 1 each time that thread is in control of the CPU when the timer interrupt occurs (every 10 milliseconds). 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.

The default algorithm calculates the CPU penalty by dividing recent CPU usage by 2. The CPU-penalty-to-recent-CPU-usage ratio is therefore 0.5. This ratio is controlled by a value called R (the default is 16). The formula is as follows: 

CPU_penalty = C * R/32

Once a second, the default algorithm divides the recent CPU usage value of every thread by 2. The recent-CPU-usage-decay factor is therefore 0.5. This factor is controlled by a value called D (the default is 16). The formula is as follows: 

C = C * D/32

For some users, the algorithm in AIX 4.3.1 does not allow enough distinction between foreground and background processes. The algorithm for calculating priority value was changed in AIX 4.3.2 to increase the impact on priorities when the nice value is changed. As the units of CPU time increase, the priority decreases with the nice effect. Using schedtune -r -d can give additional control over the priority calculation by setting new values for R and D. See Tuning with the schedtune Command for further information.

The algorithm guarantees that threads whose nice values are the default of 20 will behave exactly as they did in AIX 4.3.1 and prior releases. When the nice value is not equal to the default, the priority will be affected more due to the use of two formulas.

Begin with the following equation: 

p_nice = base priority + nice value

Now use the following formula: 

If p_nice > 60,
 then x_nice = (p_nice * 2) - 60,
 else x_nice = p_nice.

If the nice value is greater than 20, then it has double the impact on the priority value than if it was less than or equal to 20. The new priority calculation (ignoring integer truncation) is as follows: 

priority value = x_nice + [(x_nice + 4)/64 * C*(R/32)]

Note: If the nice value is the default, the formulas for AIX 4.3.1 and AIX 4.3.2 yield the same results.

Tuning with the schedtune Command

Tuning is accomplished through two options of the schedtune command: -r and -d. Each option specifies a parameter that is an integer from 0 through 32. The parameters are applied by multiplying by the parameter's value and then dividing by 32. The default r and d values are 16, which yields the same behavior as the original algorithm [(D=R=16)/32=0.5]. The new range of values permits a far wider spectrum of behaviors. For example: 

# /usr/samples/kernel/schedtune -r 0

[(R=0)/32=0, (D=16)/32=0.5] would mean that the CPU penalty was always 0, making priority a function of the nice value only. No background process would get any CPU time unless there were no dispatchable foreground processes at all. The priority values of the threads would effectively be constant, although they would not technically be fixed-priority threads.

# /usr/samples/kernel/schedtune -r 5

[(R=5)/32=0.15625, (D=16)/32=0.5] would mean that a foreground process would never have to compete with a background process started with the command nice -n 10. The limit of 120 CPU time slices accumulated would mean that the maximum CPU penalty for the foreground process would be 18. 

# /usr/samples/kernel/schedtune -r 6 -d 16

[(R=6)/32=0.1875, (D=16)/32=0.5] would mean that, if the background process were started with the command nice -n 10, 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. 

# /usr/samples/kernel/schedtune -r 32 -d 32

[(R=32)/32=1, (D=32)/32=1] would mean that long-running threads would reach a C value of 120 and remain there, contending on the basis of their nice values. New threads 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 threads.

Here are some guidelines for R and D:

If you conclude that one or both parameters need to be modified to accommodate your workload, you can enter the schedtune command while logged on as root user. The changed values will remain until the next schedtune command modifies them or until the next system boot. Values can be reset to their defaults with the command schedtune -D, but remember that all schedtune parameters are reset by that command, including VMM memory load control parameters. To make a change to the parameters that will persist across boots, add an appropriate line at the end of the /etc/inittab file.

Example of a Priority Calculation

The example shows R=4 and D=31 and assumes no other runnable threads: 

current_effective_priority
 | base process priority
 | | nice value
 | | | count (time slices consumed)
 | | | | (schedtune -r)
 | | | | |
 time 0 p = 40 + 20 + (0 * 4/32) = 60
 time 10 ms p = 40 + 20 + (1 * 4/32) = 60
 time 20 ms p = 40 + 20 + (2 * 4/32) = 60
 time 30 ms p = 40 + 20 + (3 * 4/32) = 60
 time 40 ms p = 40 + 20 + (4 * 4/32) = 60
 time 50 ms p = 40 + 20 + (5 * 4/32) = 60
 time 60 ms p = 40 + 20 + (6 * 4/32) = 60
 time 70 ms p = 40 + 20 + (7 * 4/32) = 60
 time 80 ms p = 40 + 20 + (8 * 4/32) = 61
 time 90 ms p = 40 + 20 + (9 * 4/32) = 61
 time 100ms p = 40 + 20 + (10 * 4/32) = 61
 .
 (skipping forward to 1000msec or 1 second)
 .
 time 1000ms p = 40 + 20 + (100 * 4/32) = 72
 time 1000ms swapper recalculates the accumulated CPU usage counts of
 all processes. For the above process:
 new_CPU_usage = 100 * 31/32 = 96 (if d=31)
 after decaying by the swapper: p = 40 + 20 + ( 96 * 4/32) = 72
 (if d=16, then p = 40 + 20 + (100/2 * 4/32) = 66)
 time 1010ms p = 40 + 20 + ( 97 * 4/32) = 72
 time 1020ms p = 40 + 20 + ( 98 * 4/32) = 72
 time 1030ms p = 40 + 20 + ( 99 * 4/32) = 72
 ..
 time 1230ms p = 40 + 20 + (119 * 4/32) = 74
 time 1240ms p = 40 + 20 + (120 * 4/32) = 75 count <= 120
 time 1250ms p = 40 + 20 + (120 * 4/32) = 75
 time 1260ms p = 40 + 20 + (120 * 4/32) = 75
 ..
 time 2000ms p = 40 + 20 + (120 * 4/32) = 75
 time 2000ms swapper recalculates the counts of all processes. For above process 120 * 31/32 = 116
 time 2010ms p = 40 + 20 + (117 * 4/32) = 74

Modifying the Scheduler Time Slice with the schedtune Command

The length of the scheduler time slice can be modified with the schedtune command. To change the time slice, use the schedtune -t option.

In AIX Version 4, the value of -t is the number of ticks for the time slice and only SCHED_RR threads will use the nondefault time slice value (see Scheduling Policy for Threads for a description of fixed priority threads).

Changing the time slice takes effect instantly and does not require a reboot.

A thread running with SCHED_OTHER or SCHED_RR scheduling policy can use the CPU for up to a full time slice (the default time slice being 1 clock tick), a clock tick being 10 ms.

In some situations, too much context switching is occurring and the overhead of dispatching threads can be more costly than allowing these threads to run for a longer time slice. In these cases, increasing the time slice might have a positive impact on the performance of fixed-priority threads. Use the vmstat and sar commands for determining the number of context switches per second.

In an environment in which the length of the time slice has been increased, some applications might not need or should not have the full time slice. These applications can give up the processor explicitly with the yield() system call (as can programs in an unmodified environment). After a yield() call, the calling thread is moved to the end of the dispatch queue for its priority level.

Recommended Links

In case of broken links please try to use Google search. If you find the page please notify us about new location
Google     
AIX and UNIX forums: More AIX and UNIX forums
AIX free perfomance tools (set of shell scripts)

Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: November 14, 2008