Using Operating Environment 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 resources? 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 the IBM 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.

These monitors can help you answer the following questions:

Often, solutions to resource utilization problems result in making trade-offs among resources. For example, you might 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 environment 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 (for example, transaction monitors and database servers). 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 usually running at very high CPU utilizations, then you need to consider SAS/SHARE tuning actions that can reduce CPU time. Two specific examples are type of server connection and whether 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 environment 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 environments 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 that 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.