And how about LPAR effects for the coupled z/OS images? If starved for CPU presumably all this can go South very fast. (This is certainly true when we’re talking about CF so is probably true - whether CTCs or CF structures - with XCF.
Cheers, Martin Sent from my iPad > On 2 May 2020, at 22:28, Mark A. Brooks <[email protected]> wrote: > > So you have only one signal structure per transport class? If your traffic is like most, the small traffic is an order of magnitude more than any other size, and it's all flowing to the same place. Each target system will have a unique list, so you get some distribution from that. But if you have high signals/sec to a given target, you may be getting some latch contention within the CF (but it all depends). Fussing with the transport class definitions will not help. If all else was well, I'd be looking to add another signal structure to the SML class. If you can't do a 5th structure, then I might consider revamping the classdefs so that I could reassign one of the other 3 structures to SML. > > However, it's not clear to me what your configuration is. I'm wondering if you are having path busy or subchannel busy conditions. Or perhaps shared engines for the CF. Just the one GP for the CF? Just the one CF? Those sorts of issues should be addressed first. What type of machine? Signal rates? > > Last I knew, the RMF %delay was based on periodic sampling, perhaps every second. They look at what XCF reports as "pending signals". If for example, 10 samples out of 100 catch XCF with a pending signal, they'd report 10% delay. So what's a pending signal? It's a signal whose send I/O has not yet completed and it's been at least a millisecond since the signal was accepted for delivery. If we assume there is nothing "funny", such as path restart or structure rebuild, then a signal is pending either because the signal is waiting for the I/O to be started (so we have queueing delay) or the I/O was started and we're waiting for the back end completion to run. You said "Async rate for IXCSTR1 is 120", by which I assume you mean average response time for the IXCSTR1 requests is 120 mics (as opposed to 120 requests/second). The standard deviation will give you a sense of the variation in the waiting for the async back end completion to run. But let's say 120 is the number. If your workload sends a burst of 20 small signals a millisecond before RMF takes their sample, you'll see %delay (XCF sends signals in batches of 4, 120 mics per batch, the 5th batch will be seen as pending). If that's the pattern, then even at 100% delay, I dare say your workload is not suffering in the least. > > So whenever RMF reports %delay for XCF, you have to go see if the XCF signal path activity reports are showing any signs of queueing. What is AVG Q LEN? What is AVAIL vs BUSY? AVG Q LEN is usually zero or close to it. I tend to be unconcerned until it becomes more than one. BUSY tends to suggest that the batches are backing up. Adding another signal path helps address both AVG Q LEN and high BUSY conditions. HOWEVER, one should always look to address factors that can contribute to these conditions: "no buffer" conditions on the inbound side, or path busy, subchannel busy delays for the CF. > > > Mark A Brooks > z/OS Sysplex Development > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN >Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
