Another factor would be how many CP's you have. If you can reduce total mips and increase CP's, you might find it works for your needs. Cutting by half seems a bit extreme, IMO.
Dave Gibney Information Technology Services Washington State University > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Tom Harper > Sent: Thursday, March 26, 2009 1:25 PM > To: [email protected] > Subject: Re: Performance problems > > Tracy, > > I believe you are seeing the effects of queuing. Consider the opposite > issue. Suppose you are having response time problems and you wish to > resolve them. Sometimes adding just a small amount of resource will > reduce your response time dramatically. The converse is true: removing > a > small amount of resource can increase your response time dramatically. > > The reason the simple math model does not reflect reality is because > each of your transactions response times consist of the sum of times > needed of each resource, plus the sum of the times waiting for that > resource. So even though the resource usage is unchanged, the wait time > for the resource (in this case, the CPU), goes up. Sometimes you can > see > this in queues at the grocery store or bank: adding a single checker or > teller can quickly reduce your time in line. The time to process your > transaction is unchanged, but the time you spend waiting got the > process > to occur is reduced, and you are happy. > > IBM has a solution for this: Capacity on Demand. You configure your > system similar to what you are proposing, but when you need additional > capacity, it is provided. It is not free, however. > > Tom Harper > IMS Utilities Development Team > Neon Enterprise Software > Sugar Land, TX > > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Adams, Tracy > Sent: Thursday, March 26, 2009 3:14 PM > To: [email protected] > Subject: Performance problems > > Okay, this is a continuation of a previous post... > > First of all we have an 88 mip cpu that is not constrained in any way. > RMF cpu intervals are 20% during the day and during the 3 hours of > batch > 100% like a good MVS system can do. > > So with the rising cost of software, mainly CICS, we are looking to cut > the mainframe's capacity in half. Now in the simplest math, batch > should double in time and daily rmf stat intervals will increase but > still not hit 100%, as long as no other constraints are revealed. > > Some basic tests have revealed results that I can't explain. > > Response time in our IDMS transactional system during the day (as > record > via PMDC writing smf records translated by MXG). > > A typical SAS model of performance for a given online transaction would > be 95% < .5, 4% < 1, 1 % > 1. > > When I set a hard cap at 90% the model looks more like 70% < .5, 15% < > 1, 10% < 2 and 5% > 2 of that 1% > 3. > > When I set the hard cap at 75% the model looks more like 50% < .5, 15 < > 1, 20% < 2 and 7% > 2 and 3% > 3. > > And when I set the hard cap at 50% the model looks more like 40% < .5, > 25 < 1, 25% < 2 and 10% > 2 and 3% > 3. And the users now users are > really complaining now. > > > RMF type 70 records (cpu) for all four scenerios (100%, 90%, 75% and > 50%) show averages in the 20% utilized. > > RMF type 74 records (IO) show avg resp in single digits. > > UIC hasn't fallen below 255 in 10 years. > > Batch... completed in the same time frame set at 25% as it did at 100%. > > So if the hard cap sets the amount of Service units consumed not the > actual speed of the processor, why is response time in the online going > so far south when the CPU is still running unconstrained? Why did > batch > not slow down? > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
