Previous Page | Next Page

Optimizing Performance

Optimizing SAS I/O

Put Catalogs and Data Sets into Separate Libraries, Using the Optimal Block Size for Each

The physical block size (BLKSIZE= ) of a SAS bound library determines both the minimum page size and the minimum unit of space allocation for the library. The 6KB default is relatively efficient across a range of device types, and it leads to lower memory requirements for catalog buffers. However, when you use the 6KB default, more DASD space is needed to hold a given amount of data because smaller blocks lead to capacity losses. In one test case on a 3380, an MXG daily PDB required 8% more tracks when it was stored in 6KB physical blocks instead of in half-track blocks.

Because the optimal block sizes for SAS catalogs and SAS data sets are not necessarily the same, consider putting catalogs and data sets into separate libraries. For catalog libraries, 6KB is a good general physical block size on any device. For data sets, choose either a full-track or half-track block size, depending on whether the library is stored on a device that supports full-track blocks.

Optimize I/O for Direct Access Bound Libraries

Overview of Optimize I/O for Direct Access Bound Libraries

Determining whether the primary access pattern you want to use is sequential or random, and then selecting an appropriate page size based on your determination, helps you optimize the performance of your SAS session. Based on the primary access pattern you are using, select an appropriate page size according to the guidelines in Sequential Processing Pattern and Random Processing Pattern.

The BUFSIZE data set option enables you to establish a non-default page size for a new SAS data set, but there are some limitations. Once determined, the page size becomes a permanent attribute of the SAS data set and influences the efficiency of both the output operation that creates the data set as well as that of subsequent read or update operations.

The minimum page size that can be specified for a SAS data set is the block size of the library that contains it. Because the library block size is fixed when the library is created, achieving optimal performance might require creating new libraries with special block sizes. You might also have to divide into separate libraries those members you access sequentially and those members you access randomly.

Sequential Processing Pattern

Use the following recommendations to optimize performance when using a sequential access pattern:

Random Processing Pattern

Use the following criteria to optimize performance when using a random access pattern:

Optimize I/O for Sequential Libraries

Sequential format bound libraries are those libraries that are processed with the TAPE engine.

Determine Whether You Should Compress Your Data

Overview of Compressing Data

Compressing data reduces I/O and disk space but increases CPU time. Therefore, whether data compression is worthwhile to you depends on the resource cost-allocation policy in your data center. Often your decision must be based on which resource is more valuable or more limited, DASD space or CPU time.

You can use the portable SAS system option COMPRESS= to compress all data sets that are created during a SAS session. Or, use the SAS data set option COMPRESS= to compress an individual data set. Data sets that contain many long character variables generally are excellent candidates for compression.

The following tables illustrate the results of compressing SAS data sets under z/OS. In both cases, PROC COPY was used to copy data from an uncompressed source data set into uncompressed and compressed result data sets, using the system option values COMPRESS=NO and COMPRESS=YES, respectively.(footnote 1) In the following tables, the CPU row shows how much time was used by an IBM 3090-400S to copy the data, and the SPACE values show how much storage (in megabytes) was used.

For the first table, the source data set was a problem-tracking data set. This data set contained mostly long, character data values, which often contained many trailing blanks.

Compressed Data Comparison 1
Resource Uncompressed Compressed Change
CPU 4.27 sec 27.46 sec +23.19 sec
Space 235 MB 54 MB -181 MB

For the preceding table, the CPU cost per megabyte is 0.1 seconds.

For the next table, the source data set contained mostly numeric data from an MICS performance database. The results were again good, although not as good as when mostly character data was compressed.

Compressed Data Comparison 2
Resource Uncompressed Compressed Change
CPU 1.17 sec 14.68 sec +13.51 sec
Space 52 MB 39 MB -13 MB

For the preceding table, the CPU cost per megabyte is 1 second.

For more information about compressing SAS data, see SAS Programming Tips: A Guide to Efficient SAS Processing.

Consider Using SAS Software Compression in Addition to Hardware Compression

Some storage devices perform hardware data compression dynamically. Because this hardware compression is always performed, you might decide not to enable the SAS COMPRESS option when you are using these devices. However, if DASD space charges are a significant portion of your total bill for information services, you might benefit by using SAS software compression in addition to hardware compression. The hardware compression is transparent to the operating environment. If you use hardware compression only, then space charges are assessed for uncompressed storage.

Consider Placing SAS Libraries in Hiperspaces

One effective method of avoiding I/O operations is to use SAS software's HIPERSPACE engine option. This option is specific to z/OS and enables you to place a SAS library in a hiperspace instead of on disk.

The major factor that affects hiperspace performance is the amount of expanded storage on your system. The best candidates for using hiperspace are jobs that execute on a system that has plenty of expanded storage. If expanded storage on your system is constrained, the hiperspaces are moved to auxiliary storage. Moving the hiperspaces to auxiliary storage eliminates much of the potential benefit of using the hiperspaces.

For more information about using hiperspaces under z/OS, see Hiperspace and DIV Libraries and Tuning SAS Applications in the MVS Environment.

Consider Designating Temporary SAS Libraries as Virtual I/O Data Sets

Treating libraries as "virtual I/O" data sets is another effective method of avoiding I/O operations. This method works well with any temporary SAS library--especially WORK. To use this method, specify UNIT=VIO as an engine option in the LIBNAME statement or LIBNAME function.

The VIO method is always effective for small libraries (<10 cylinders). If your installation has set up your system to allow VIO to go to expanded storage, then VIO can also be effective for large temporary libraries (up to several hundred cylinders). Using VIO is most practical during evening and night shifts when the demands on expanded storage and on the paging subsystem are typically light.

The VIO method can also save disk space because it is an effective way of putting large paging data sets to double use. During the day, these data sets can be used for their normal function of paging and swapping back storage; during the night, they become a form of temporary scratch space.

FOOTNOTE 1:   When you use PROC COPY to compress a data set, you must include the NOCLONE option in your PROC statement. Otherwise, PROC COPY propagates all the attributes of the source data set, including its compression status. [arrow]

Previous Page | Next Page | Top of Page