Tuning Tips for Applications That Use SAS/SHARE Software : Using Operating System Tools
Up to this point, we have been looking at SAS application and server performance
from an internal point of view. Now we turn to an external point of view.
By performance externals, we mean several things. First, at what rate is a
server consuming resources such as CPU, memory, and DASD I/O? Second, with
what other workloads is a server competing for these resource? And third,
what policy is being used to manage a server's access to resources with respect
to other work in the system?
There are several monitors available for MVS and VM
to help you analyze a server's resource utilization and contention with other
workloads. On MVS, most sites license IBMTM's RMF product. RMF Monitor
II and Monitor III support interactive analysis of SAS/SHARE performance.
Also available on MVS are Candle Corporation's Omegamon and Landmark System's
TMON for MVS. Prominent products on VM include Omegamon from Candle Corporation
and XAMAP and XAMON from Velocity Software.
Questions these monitors can help you answer include:
Often, solutions to resource utilization problems result
in making trade-offs among resources. For example, you may be able to reduce
I/O by allocating additional buffers. But the additional buffer allocation
will take more memory. Use of one of these monitors can help you evaluate
the effectiveness of the trade-off.
It is beyond the scope of this paper to tell you exactly
how to use specific operating system performance monitors. We are making the
non-trivial assumption that you or someone else on your staff have that knowledge.
Basically, every system has three principal resources: CPU, I/O, and memory.
We will look at examples of managing each of these for servers:
The most
critical factor here is assuring that your servers are getting a reasonable
share of the available CPU time. Servers in general ought to run at a higher
priority than clients and at the same priority as other types of server or
service work on your system (transaction monitors, database servers, etc.).
You can tune your SAS/SHARE application meticulously only to be foiled if
a background process (for example) is preventing your servers from getting
CPU time.
If CPU time is a scarce resource on your system, that
is your system is generally running at very high CPU utilizations, then you
need to consider SAS/SHARE tuning actions which can reduce CPU time. Two specific
examples are type of server connection and whether or not to use data compression.
The first
thing to consider here is the amount of contention with other work on the
system. Are your SAS libraries competing with other work on channels, disk
controllers, or disk drives which are too busy? Too busy on I/O channels and
control units is highly specific to each operating system and hardware vendor.
But in general it is safe to say that if a disk drive is consistently above
twenty percent busy, then off-loading work from that drive ought to be considered.
If there is no significant contention with other work,
then you need to consider spreading application libraries using SAS/SHARE
across multiple disks.
If waiting for I/O is still a problem for your servers,
then you need to consider SAS/SHARE tuning options which can reduce I/O time.
These include using smaller page sizes for randomly-accessed data, adding
indexes for randomly-accessed data, and possibly using data compression. Data
compression is a specific example of the resource trade-off problem mentioned
earlier. Data compression can reduce I/O and disk storage but will increase
CPU time.
Memory is an interesting resource in that it directly affects both CPU
and I/O resource consumption. Too little memory increases both. Additional
memory can reduce both. The most critical factor here is to ensure that your
servers have sufficient memory to prevent excessive wait for paging. Most
operating systems have controls to differentiate the amount of memory given
to various workloads on the system.
If real memory is a scarce resource on your system,
then you need to consider SAS/SHARE tuning actions which reduce memory consumption.
Chief among these are reducing data set page sizes to reduce I/O buffer memory
requirements and using shared SAS system images where possible.
Copyright © 1999 by SAS Institute Inc., Cary, NC, USA. All rights reserved.
