Unless you are purchasing a software package that comes with detailed resource-requirement documentation, estimating resources can be the most difficult task in the performance-planning process. The difficulty has several causes, as follows:
A useful guideline is that, the higher the level of abstraction, the more caution is needed to ensure that one does not receive a performance surprise. Consider carefully the data volumes and number of iterations implied by some apparently harmless constructs.
Two approaches deal with resource-report ambiguity and variability. The first is to ignore the ambiguity and to keep eliminating sources of variability until the measurements become acceptably consistent. The second approach is to try to make the measurements as realistic as possible and describe the results statistically. Note that the latter yields results that have some correlation with production situations.
Make your estimate as realistic as the specific situation allows, using the following guidelines:
Keep in mind that independent software vendors (ISV) often have sizing guidelines for their applications.
In estimating resources, we are primarily interested in four dimensions (in no particular order):
The following sections discuss how to determine these values in various situations.
If the real program, a comparable program, or a prototype is available for measurement, the choice of technique depends on the following:
Using a dedicated system is the ideal situation because we can use measurements that include system overhead as well as the cost of individual processes.
To measure overall system performance for most of the system activity, use the vmstat command:
# vmstat 5 >vmstat.output
This gives us a picture of the state of the system every 5 seconds during the measurement run. The first set of vmstat output contains the cumulative data from the last boot to the start of the vmstat command. The remaining sets are the results for the preceding interval, in this case 5 seconds. A typical set of vmstat output on a system looks similar to the following:
kthr memory page faults cpu ----- ----------- ------------------------ ------------ ----------- r b avm fre re pi po fr sr cy in sy cs us sy id wa 0 1 75186 192 0 0 0 0 1 0 344 1998 403 6 2 92 0
To measure CPU and disk activity, use the iostat command:
# iostat 5 >iostat.output
This gives us a picture of the state of the system every 5 seconds during the measurement run. The first set of iostat output contains the cumulative data from the last boot to the start of the iostat command. The remaining sets are the results for the preceding interval, in this case 5 seconds. A typical set of iostat output on a system looks similar to the following:
tty: tin tout avg-cpu: % user % sys % idle % iowait
0.0 0.0 19.4 5.7 70.8 4.1
Disks: % tm_act Kbps tps Kb_read Kb_wrtn
hdisk0 8.0 34.5 8.2 12 164
hdisk1 0.0 0.0 0.0 0 0
cd0 0.0 0.0 0.0 0 0
To measure memory, use the svmon command. The svmon -G command gives a picture of overall memory use. The statistics are in terms of 4 KB pages (example from AIX 4.3.3):
# svmon -G
size inuse free pin virtual
memory 65527 65406 121 5963 74711
pg space 131072 37218
work pers clnt
pin 5972 0 0
in use 54177 9023 2206
In this example, the machine's 256 MB memory is fully used. About 83 percent of RAM is in use for working segments, the read/write memory of running programs (the rest is for caching files). If there are long-running processes in which we are interested, we can review their memory requirements in detail. The following example determines the memory used by a process of user hoetzel.
# ps -fu hoetzel
UID PID PPID C STIME TTY TIME CMD
hoetzel 24896 33604 0 09:27:35 pts/3 0:00 /usr/bin/ksh
hoetzel 32496 25350 6 15:16:34 pts/5 0:00 ps -fu hoetzel
# svmon -P 24896
------------------------------------------------------------------------------
Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd
24896 ksh 4592 1456 2711 5615 N N
Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range
4411 d work shared library text 2619 0 1187 1315 0..65535
0 0 work kernel seg 1908 1455 1399 4171 0..32767 :
65475..65535
703c 1 pers code,/dev/hd2:4188 58 0 - - 0..58
5176 2 work process private 4 1 104 108 0..129 :
65309..65535
1465 - pers /dev/hd2:16866 2 0 - - 0..1
4858 - pers /dev/hd2:8254 1 0 - - 0..0
18c5 - pers /dev/andy:207 0 0 - - 0..0
783d f work shared library data 0 0 21 21 0..3492
The working segment (5176), with 4 pages in use, is the cost of this instance of the ksh program. The 2619-page cost of the shared library and the 58-page cost of the ksh program are spread across all of the running programs and all instances of the ksh program, respectively.
If we believe that our 256 MB system is larger than necessary, use the rmss command to reduce the effective size of the machine and remeasure the workload. If paging increases significantly or response time deteriorates, we have reduced memory too much. This technique can be continued until we find a size that runs our workload without degradation. See Assessing Memory Requirements Through the rmss Command for more information on this technique.
The primary command for measuring network usage is the netstat program. The following example shows the activity of a specific Token-Ring interface:
# netstat -I tr0 5
input (tr0) output input (Total) output
packets errs packets errs colls packets errs packets errs colls
35552822 213488 30283693 0 0 35608011 213488 30338882 0 0
300 0 426 0 0 300 0 426 0 0
272 2 190 0 0 272 2 190 0 0
231 0 192 0 0 231 0 192 0 0
143 0 113 0 0 143 0 113 0 0
408 1 176 0 0 408 1 176 0 0
The first line of the report shows the cumulative network traffic since the last boot. Each subsequent line shows the activity for the preceding 5-second interval.
The techniques of measurement on production systems are similar to those on dedicated systems, but we must be careful to avoid degrading system performance.
Probably the most cost-effective tool is the vmstat command, which supplies data on memory, I/O, and CPU usage in a single report. If the vmstat intervals are kept reasonably long, for example, 10 seconds, the average cost is relatively low. See Identifying the Performance-Limiting Resource for more information on using the vmstat command.
By partial workload, we mean measuring a part of the production system's workload for possible transfer to or duplication on a different system. Because this is a production system, we must be as unobtrusive as possible. At the same time, we must analyze the workload in more detail to distinguish between the parts we are interested in and those we are not. To do a partial measurement, we must discover what the workload elements of interest have in common. Are they:
Depending on the commonality, we could use one of the following:
# ps -ef | grep pgmname # ps -fuusername, . . . # ps -ftttyname, . . .
to identify the processes of interest and report the cumulative CPU time consumption of those processes. We can then use the svmon command (judiciously) to assess the memory use of the processes.
Many tools are available for measuring the resource consumption of individual programs. Some of these programs are capable of more comprehensive workload measurements as well, but are too intrusive for use on production systems. Most of these tools are discussed in depth in the chapters that discuss tuning for minimum consumption of specific resources. Some of the more prominent are:
It is impossible to make precise estimates of unwritten programs. The invention and redesign that take place during the coding phase defy prediction, but the following guidelines can help you to get a general sense of the requirements. As a starting point, a minimal program would need the following:
To the above, add the basic cost allowances for demands implied by the design (the units given are for example purposes only):
The best method for estimating peak and typical resource requirements is to use a queuing model such as BEST/1. Static models can be used, but you run the risk of overestimating or underestimating the peak resource. In either case, you need to understand how multiple programs in a workload interact from the standpoint of resource requirements.
If you are building a static model, use a time interval that is the specified worst-acceptable response time for the most frequent or demanding program (usually they are the same). Determine which programs will typically be running during each interval, based on your projected number of users, their think time, their key entry rate, and the anticipated mix of operations.
Use the following guidelines:
Note: Remember that these guidelines are intended for use only when no extensive measurement is possible. Any application-specific measurement that can be used in place of a guideline will considerably improve the accuracy of the estimate.