8.5 Other performance recommendations

< Day Day Up >

The remaining performance-related recommendations apply equally to active and funnel-type log streams and are documented in this section.

8.5.1 Which CF log streams to place in the same structure

There are two attributes of a log stream that should be borne in mind when deciding which log streams should reside in a given structure. In addition, it is recommend that you not place more than 10 log streams in a given structure. You can enforce this by specifying LOGSNUM(10) when you define the structure in the LOGR policy.

The first attribute is the ratio between the MAXBUFSIZE specified for the structure and the actual average buffer size of the log stream. The actual buffer size for each log stream can be found in the field entitled "AVERAGE BUFFER SIZE" in the IXGRPT1 report. This ratio determines how many elements are needed for each log block, and therefore the entry-to-element ratio. This was discussed in "The entry-to-element ratio" on page 26. If the log streams in a structure have very different average buffer sizes, it is likely that the entry-to-element of the structure will only suit a subset, or maybe even none, of the log streams in the structure.

The average buffer size of a log stream can vary over time, so this is not an exact science, however, try to avoid placing log streams with consistently very large average buffer sizes in the same structure as ones with consistently very small ones.

The other attribute to be considered is the volume of data being written to the log stream. The number of bytes written to the log stream over an SMF interval is reported in field "BYT WRITTN BY USERS IXGWRITES" in the IXGRPT1 report. Remember that the elements in a structure are divided equally between all connected log streams in that structure. So, if you have a very busy and a very idle log stream in the same structure, the busy one is likely to be short of storage, doing very frequent offloads, while the other log stream will have far more storage than it requires and therefore hardly ever doing an offload.

Traditional wisdom for placing DASD data sets is that busy data sets should be separated from each other and placed on volumes with idle data sets. However, for optimum CF log stream performance, log streams with high write rates should be placed in the same structure—one that has a reasonably large size. And log streams with low writes should be placed together in another structure, presumably one with a lot less storage.

8.5.2 System Logger DASD performance

System Logger uses three types of data sets: its own CDSs, staging data sets, and offload data sets. While the CDSs are not normally very busy, during recovery processing they can get quite busy. Therefore, to ensure timely recovery from failures, the LOGR CDSs should be placed on high performance DASD, along with the other sysplex-related CDSs.

The staging data sets associated with busy log streams can potentially be a bottleneck to System Logger performance. Remember that IXGWRITEs are synchronous—the requestor will not get a response from System Logger until the I/O to the staging data set either completes or fails. Therefore, at least the staging data sets associated with the busier log streams should be placed on high performance devices. You can use your SMS ACS routines to ensure this happens.

The last type of data sets are the offload ones. Generally speaking, the performance of these data sets is not as critical as the staging data sets. What is more important is that they are placed on volumes that are not subject to RESERVEs as this can delay allocation processing when System Logger is trying to move data to an offload data set from interim storage. Therefore, when placing these data sets (in your ACS routines), attempt to select devices with reasonable performance that are unlikely to be the targets of a RESERVE.

In addition to placement of the staging data sets, the CI Size of the data sets can have an affect on System Logger performance. While the staging data sets must have a CI Size of 4 KB, the offload data sets should have a CI Size of 24K. The best way to effect this is to use a data class for all offload data sets that is defined with this CI Size.

8.5.3 Indicators of potential problems

There are a number of fields in the IXGRPT1 report that you should monitor that warn you of potential sub-optimal performance.

The first is significant number of "Type 3" writes for any CF log stream. These are a result of an IXGWRITE to a log stream where there are already more than 90% of the elements are in use. This is an indicator of either a problem in offload processing, or else that the interim storage is significantly undersized for this log stream.

Another field to monitor is DASD SHFTS, particularly in relation to the number of offloads. Assuming that offloads are being initiated reasonably frequently, the number of DASD SHIFTS (that is, the number of times a new offload data set had to be allocated) should be a small percentage of the number of offloads. If you have a significant number of DASD SHIFTS, it is an indicator that the offload data sets are much smaller than they should be (possibly because an appropriate LS_SIZE was not specified on the log stream definition in the LOGR policy). In addition, for an active log stream, where you want to avoid the use of offload data sets completely, the presence of DASD SHIFTS is an indicator that either the log stream interim storage is too small, or else there is a problem with the application resulting in log records being held open for much longer than they should be. This is discussed in "IXGRPT1 observations and possible actions" on page 183.

< Day Day Up >