Transcript 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
• 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
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
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
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
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
Code
.COMMONX
SVC122
SVC120
SVC18
Func
PDSMAN
Load
Getmain
bldl
CPU PCT
5.59
5.72
4.45
1.53
17.29
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
Code
.COMMONX
SVC122
SVC120
SVC18
Func
Base
Preload
%change
PDSMAN
5.59
4.57 -18.25%
Load
5.72
3.58 -37.41%
Getmain
4.45
3.58 -19.55%
bldl
1.53
1.61
5.23%
17.29
13.34
-22.85%
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)
Program
.COMMONX
SVC122
SVC120
SVC18
Func
Base
PDSMAN
5.59
Load
5.72
Getmain
4.45
bldl
1.53
17.29
preload%change
steplib%change
4.57 -18.25%
0.72 -87.12%
3.58 -37.41%
1.22 -78.67%
3.58 -19.55%
2.88 -35.28%
1.61
5.23%
1.08 -29.41%
13.34
5.9
-22.85%
-65.88%
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!
Metric
2/11/2010
4/4/2011
% change
IMSA TRANs
IMSC TRANS
4,992,456
2,996,231
5,551,697
3,352,235
+11.2%
+11.9%
IMSA AVG SERVICE TIME
IMSC AVG SERVICE TIME
0.1100
0.0828
0.0749
0.0604
-32%
-27%
IMSA AVG CPU/TRAN
IMSC AVG CPU/TRAN
0.0153
0.00504
0.0114
0.0036
-25%
-28%
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…