Previous topic |
Next topic |
Contents |
Contact z/OS |
Library |
PDF
Shortage of CF subchannels z/OS MVS Setting Up a Sysplex SA23-1399-00 |
|
Another possible cause for higher service times and excessive queuing is a shortage in the number of CF links from the sending CECs. Modern link types support up to 32 subchannels per CHPID (with 1x InfiniBand). The data to be sent to the CF is loaded into these subchannels. If no subchannels are available, ASYNC requests are queued. Non-immediate SYNC requests are changed to ASYNC requests (which are then also queued). Immediate SYNC requests spin waiting for the next available subchannel in most cases; while some locking requests can be changed to ASYNCH requests and then be queued. As of z/OS® V1R10, some locking operations and IXLSYNCH operations can support a queuing protocol when no subchannels are available, which is similar to the current handling of CF list and cache requests. This enhancement is made to eliminate the costly CPU-synchronous spins, and thus reduce the significant CPU overhead when processors must wait for an active CF operation to complete so that its subchannel can be re-used to drive the next request. Data about the delayed requests is reported on the RMF™ CF Subchannel Activity report as SYNC and ASYNC DELAYED REQUESTS and summarized on the TOTAL line. For those requests which experience a delay, the duration of the delay is reported separately (/DEL). (Some of these fields were added or changed by RMF APAR OW13536 which was included in OS/390® R2. WSC FLASH 9609 describes the changes and provides a detailed information about the data on the reports). You can assess the impact of the subchannel delay, by looking at the /ALL field. This takes the delay time for the requests that were delayed and amortizes it over all the requests. So, for example, consider a system whose 1930 SYNC requests encountered a subchannel busy. Each of these is delayed for an average of 461.2 microseconds. Because the guideline for SYNC request service times is 250-350 microseconds, this looks like a problem. However, when this delay is amortized over all the SYNC requests under /ALL, the report indicates only 3.8 microseconds. As a guideline, the sum of the SYNC and ASYNC requests delayed
(TOTAL - % OF REQ) should be less than 10% of all requests. If the
percentage of requests queued is greater than this, you should:
|
Copyright IBM Corporation 1990, 2014
|