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

Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

AIX performance tuning


Performance tuning

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


Open source software for AIX

Database Performance Tuning Oracle Performance Tuning Tivoli perfomance tuning
no uptime ps top nice sar      
vmstat ipstat procstat nfsstat   Troubleshooting Linux Performanc Tips Humor Etc

The word performance is multi-faceted, with trade-off decisions to be made at each corner. To take the guesswork out of any such decision, you must be backed by good knowledge of expected behavior and learn to use a set of tools available for AIX performance monitoring.  You must have a well-defined mechanism for measuring the effect of any changes you make.

Because AIX environment with time usually becomes more complex and you add applications and systems, you should periodically revisit your initial hardware configuration to improve performance.

If data base is used you need to follow recommendations for setting kernel parameters that are provided in corresponding database documentation of installation guide.

If Java is used you need to follow Java specific recommendations:

Maximizing Java performance on AIX Part 1 The basics

One common AIX tuning tip is to increase number of file descriptors beacuse system default 2000 is too low for systems like Oracle or Tivoli.  See  AIX file descriptors

Tuning AIX systems

The other is to tune TCP stack:

Top updates

Bulletin Latest Past week Past month
Google Search


Old News ;-)


In most cases you need to adjust some network tunables on server systems. Most of these settings concern different network protocol buffers. You can set these buffer sizes system-wide with the no command (refer to 6.7.1, The no command), or use the Interface Specific Network Options1 (ISNO) for each network adapter. For more details about ISNO, see AIX 5L Version 5.3 System Management Guide: Communications and Networks, SC23-4909, and AIX 5L Version 5.3 Commands Reference, SC23-4888.

The change will only apply to the specific network adapter if you have enabled ISNO with the no command as in the following example:

			Example 2-6 shows how to use the
			lsattr command to check the current settings for an network 
			interface, in this case token-ring: 

Example 2-6 Using lsattr to check adapter settings


lsattr -H -El tr0 -F"attribute value"

mtu_4         1492
mtu_100       1492
arp           on
hwloop        off
security      none
rfc1323       0
tcp_sendspace 16384
tcp_recvspace 16384


The highlighted part in Example 2-6 indicates the ISNO options. Before applying ISNO settings to interfaces by using the chdev command, you can use ifconfig to set them on each adapter. Should you for some reason need to reset them and are unable to log in to the system, the values will not be permanent and will not be activated after IPL. For this reason it is not recommended to set ISNO values using ifconfig in any system startup scripts that are started by init (from /etc/inittab).

1There are five ISNO parameters for each supported interface; rfc1323, tcp_nodelay, tcp_sendspace, tcp_recvspace, and tcp_mssdflt. When set, the values for these parameters override the system-wide parameters of the same names that had been set with the no command. When ISNO options are not set for a particular interface, system-wide options are used. Options set by an application for a particular socket using the setsockopt subroutine override the ISNO options and system-wide options set by using the chdev, ifconfig, and no commands. - Tuning cpu, tcp, disk io, memory on aix for better performance

CPU, Memory & Kernel


'ulimit' defines file descriptors limits.  It specifies the number of open files permitted. If this value is set too low, a memory allocation error will occur on AIX and a too many files open will be logged to the to the stderr log file. Set this value higher than the default system value. For large multi-processor machines, set to unlimited.

# ulimit -a   // to query
# ulimit -n <new_value>  // to set to a new value
# ulimit -n -1   // to set it to unlimited

Maximum Number of Processes Per User

'maxuproc' defines the max number of processes each AIX user can 'fork'. If it is set too low, you may not be able to create high number of database agents necessary to handle connections from your application.  So it is recommended to set this to at least 4096. 

To query current setting:
# lsattr -D -l sys0 -a maxuproc

To set to a different value:
# chdev -l sys0 -a maxuproc='4096'

Shared Memory Segments

The 'EXTSHM' environment variable defines the max number of memory segments shared by all user-mode applications.  Some database servers, such as IBM DB2, relies on this environment variable to support large workloads.  To set it, add the following lines to a user's profile:

export EXTHSM


In high volume environment, TCP layer on AIX should be tuned to the similar values listed below:

Tune TCP

To display a list of current tunable values, use:
/usr/sbin/no -a

To make TCP changes permanent, add the following lines into the /etc/ file:

/usr/sbin/no -o sb_max=6192000
/usr/sbin/no -o tcp_sendspace=4096000
/usr/sbin/no -o tcp_recvspace=4096000
/usr/sbin/no -o udp_sendspace=65536
/usr/sbin/no -o udp_recvspace=655360
/usr/sbin/no -o rfc1323=1
/usr/sbin/no -o ipqmaxlen=150
/usr/sbin/no -o clean_partial_conns=true

Ethernet Device Driver Properties

To display a list of current ethernet adapter device driver settings such as MTU, IPs, etc., use:
lsattr -E -l en2

where en2 is the adapter name - chances are you have several, en0, en1, etc. A typical output will have the following:

root@pw4:~# lsattr -E -l en2
alias4                      IPv4 Alias including Subnet Mask           True
alias6                      IPv6 Alias including Prefix Length         True
arp           on            Address Resolution Protocol (ARP)          True
authority                   Authorized Users                           True
broadcast                   Broadcast Address                          True
mtu           1500          Maximum IP Packet Size for This Device     True
netaddr      Internet Address                           True
netaddr6                    IPv6 Internet Address                      True
netmask Subnet Mask                                True
prefixlen                   Prefix Length for IPv6 Internet Address    True
remmtu        576           Maximum IP Packet Size for REMOTE Networks True
rfc1323                     Enable/Disable TCP RFC 1323 Window Scaling True
security      none          Security Level                             True
state         up            Current Interface Status                   True
tcp_mssdflt                 Set TCP Maximum Segment Size               True
tcp_nodelay                 Enable/Disable TCP_NODELAY Option          True
tcp_recvspace 1024000       Set Socket Buffer Space for Receiving      True
tcp_sendspace 1024000       Set Socket Buffer Space for Sending        True

To change the adapter network settings, one way is to run the command line tool chdev:

# ifconfig en0 detach
# chdev -l ent0 -a tx_que_size=128
# ifconfig en0 hostname up

where tx_que_size is an example parameter.  The second way to change them is through the SMIT, for example:

   1. Detach the interface by running the following command:

      # ifconfig en0 detach

      where en0 represents the adapter name.
   2. Use SMIT to display the adapter settings. Select Devices -> Communications -> adapter type -> Change/Show...
   3. Move the cursor to the field you want to change, and press F4 to see the minimum and 
      maximum ranges for the field (or the specific set of sizes that are supported).
   4. Select the appropriate size, and press Enter to update the ODM database.
   5. Reattach the adapter by running the following command:

      # ifconfig en0 hosthame up

Example SMIT screen:

Change/Show Characteristics of an Ethernet Adapter

Type or select values in entry fields.
Press Enter AFTER making all desired changes.

                                                        [Entry Fields]
  Ethernet Adapter                                    ent2
  Description                                         10/100/1000 Base-TX PCI-X Adapter (14106902)
  Status                                              Available
  Location                                            1V-08
  Receive descriptor queue size                      [1024]             +#
  Transmit descriptor queue size                     [512]              +#
  Software transmit queue size                       [8192]             +#
  Transmit jumbo frames                               no                +
  Enable hardware transmit TCP resegmentation         yes               +
  Enable hardware transmit and receive checksum       yes               +
  Media Speed                                         Auto_Negotiation  +
  Enable ALTERNATE ETHERNET address                   no                +
  ALTERNATE ETHERNET address                         [0x000000000000]   +
  Apply change to DATABASE only                       no                +

F1=Help                       F2=Refresh                    F3=Cancel                     F4=List
Esc+5=Reset                   Esc+6=Command                 Esc+7=Edit                    Esc+8=Image
Esc+9=Shell                   Esc+0=Exit                    Enter=Do

Disk I/O

Tune FS Performance

The following file system mount option settings allow you to take advantage of caching, throughput optimization, and performance of UNIX attached external storage device, like a SAN. 

Update the /etc/filesystems, and modify the wanted file system section(s) to use 'dio':

    dev = /dev/fwvol
    vfs = jfs2
    log = INLINE
    mount = true
    options = dio,rw
    account = false

Enabling file system direct I/O, on AIX, allows the file system buffer cache to be bypassed which eliminates the double buffering of data which can adversely affect file system I/O performance. For changes to take effect, you may run 'mount -a', if the file system you are modifying is not mounted. If the file system is mounted it will need to be unmounted and then remounted or a system reboot will need to be executed.

To reduce the workload on system make sure you are only running the daemons you need, disabling the unnecessary daemons can significantly improve the load on system.  Know what your AIX server is used for, and disable the following recommended daemons:

accounting : The command accton enables system-wide accounting services, if you are not using accounting on your system then disabling accton command will increase productivity of your system.
biod: Daemon allows the system to access filesystems via NFS.
comsat: program that prints "you have new mail" on your screen.
lpd or lpsched: printer daemons.
mounted: this daemon listens for remote mount requests.
nfsd: This Daemon services NFS requests from remote systems.
nntpd : This Daemon supports USENET network news services.
quotas: /etc/rc quotaon enables disk quota checking.
rlogind: services rlogin and rsh commands.
routed: This daemon routes network packets destined for other networks. If your local network has only one gateway to the outside world you can disable routed. Then make sure that /etc/rc.local has a line such as route add default gateway 1
rwhod: This daemon provides information about users on other systems, rwho and ruptime commands use this daemon.
sendmail: This provides e-mail services both internally and externally (between other systems). Sendmail uses lot of memory.
talkd: This Daemon supports the talk command.
timed: This daemon attempts to synchronize system clocks across a network. If you are working across different systems then this is necessary.
ypbind: This daemon lets the system look up information in NIS database. Atleast one system must be running ypserv before you can run ypbind.
ypserv: This daemon makes a system act as an NIS server, the system that can send information about the NIS database to other systems on network. It must not be running if system isn't a NIS server.

[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 manual)

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

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

Free tool


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 performance optimization articles

[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.


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:

[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.


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.

... ... ...


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:

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.

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");

if ( Priority < 50 ) {
printf(" Priority must be >= 50 \n");

while (*argv) {
ReturnP = setpri(ProcessID, Priority);
if ( ReturnP > 0 )
printf("pid=%d new pri=%d old pri=%d\n",
else {
perror(" setpri failed ");

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
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:

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
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
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:

| 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

Softpanorama Top Visited

Softpanorama Recommended

AIX and UNIX forums: More AIX and UNIX forums
AIX free performance tools (set of shell scripts)\



Groupthink : Understanding Micromanagers and Control Freaks : Toxic Managers : BureaucraciesHarvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Two Party System as Polyarchy : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


Skeptical Finance : John Kenneth Galbraith : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Oscar Wilde : Talleyrand : Somerset Maugham : War and Peace : Marcus Aurelius : Eric Hoffer : Kurt Vonnegut : Otto Von Bismarck : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Oscar Wilde : Bernard Shaw : Mark Twain Quotes


Vol 26, No.1 (January, 2013) Object-Oriented Cult : Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks: The efficient markets hypothesis : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor


The Last but not Least

Copyright © 1996-2014 by Dr. Nikolai Bezroukov. was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine. This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting hosting of this site with different providers to distribute and speed up access. Currently there are two functional mirrors: (the fastest) and


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: July 18, 2014