1 / 10

IMS performance savings

IMS performance savings. Background. IMS is backend system for Standard Life SOA applications Distributed applications Increased CPU consumption in IMS transactions SEP 10 Coincident with Z/OS 1.11- not proven to be the cause Variable, but up to 12% Reduced after IMS V11 upgrade in NOV 10

amalie
Download Presentation

IMS performance savings

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IMS performance savings

  2. Background • IMS is backend system for Standard Life SOA applications • Distributed applications • Increased CPU consumption in IMS transactions SEP 10 • Coincident with Z/OS 1.11- not proven to be the cause • Variable, but up to 12% • Reduced after IMS V11 upgrade in NOV 10 • But came back in Jan 11 • Various PMRs open with IBM, various PTFs suggested, but none identified the issue • DASD response times fluctuating, affecting IMS WADS • IMS input queue time doubled beginning of JAN! • Other unexplained SOA performance issues

  3. Background • Z9 EOS announced prior to Z196 • Go for Z10, or wait for Z NEXT? • Z9 upgraded in 2010, 2 engines added • No further upgrades possible (EOS) • Capacity for 2 years? • IMS CPU increase blew capacity paln • Capacity issue for tax year end APR 11

  4. Performance Issues • WADS response time critical to IMS • PPRC requires acknowledgement from secondary copy before I/O completes. • Seeing 12 millisec response times • Capacity of SRDF ports too low • Not monitored well • Actual problem was the CPU busy on the DASD hardware. • Box reconfigured to increase SRDF links • Monitoring put in place • IMS happy again

  5. Performance Issues • Unattributable performance issues. • Everyone says “My bit is OK” • IMS transaction responses fine • Found to be MQ buffering issue • Buffers and pagesets shared between online and batch queues • Buffers too small • Discovered with IMS log analysis, long program end to message dequeue. • CSQP020E =MVMA CSQP1RSW Buffer pool x is too small • Other MQ settings running ‘out of the box’ • 2 MQ internal traces on, wasting CPU cycles

  6. Capacity Issues • Used strobe on MPRs to look at CPU attribution • But no ‘before’ to compare • Immediately saw a lot of cycles involving program load

  7. Capacity Issues • Revised program preload lists • Switch preload off in one region of each main class • Used PDSM SMF records to get loaded module list • Rebuilt preload lists • 10% CPU reduction in our biggest system • Even more in our smaller system

  8. Capacity Issues • Still a lot of CPU in PDSMAN • Due to a steplib we could not easily get rid of • Application lib was in linklist – 79th in concatonation..hmmm • Experimented with program loads in batch • Found a way to reduce program load CPU overhead by 40% • Add the linklist lib to the steplib of the mpr • Define as a private library to LLA, with freeze option (prevents I/O)

  9. Comparative IMS data • Comparing our tax year end peak to the previous peak of the last 6 months • The actual savings are much greater than predicted!

  10. Further Savings? • PWFI may save additional 5-10% • Like wait for input, but self tuning, not dedicated regions • Highest used programs stay scheduled • Reduced L/E rununit start up and termination • Application programs MUST be properly reusable • Tried it once before and got burned • Use log analysis to verify programs that have processed more than one tran in a scheduling • Use regression testing tool…

More Related