SMF30 record length
Cobe Xu
We have 2 lpars in sysplex,one is for production,the other is for
development,both are in zos1.9.
Recently we noticed the smf datasets' size have huge difference, and
we found the main reason is the type 30 record length is different.Any idea
of the reasons?
below is one sample from SMFDUMP output.
Production:
START DATE-TIME 12/15/2009-00:05:16 END DATE-TIME
12/16/2009-00:05:25
RECORD RECORDS PERCENT AVG. RECORD MIN. RECORD MAX.
RECORD RECORDS
TYPE READ OF TOTAL LENGTH LENGTH
LENGTH WRITTEN
2 47 .00 % 18.00
18 18 1
3 47 .00 % 18.00
18 18 1
4 35,622 .61 % 215.00
215 215 0
5 7,462 .13 % 153.88
145 160 0
14 171,795 2.96 % 398.99
318 756 0
15 172,736 2.98 % 371.35
318 636 0
16 7,756 .13 % 805.24 592
2,296 0
17 33,394 .58 % 100.00
100 148 0
18 825 .01 % 144.00
144 144 0
19 2,072 .04 % 72.00
72 72 0
20 8,687 .15 % 99.81
91 106 0
21 1,344 .02 % 88.00
88 88 0
23 24 .00 % 258.00
258 258 0
26 7,196 .12 % 450.89
442 457 0
30 107,020 1.85 % 1,605.45 398
32,738 0
34 86 .00 % 215.00
215 215 0
35 86 .00 % 148.80
147 150 0
36 18 .00 % 214.00
214 214 0
38 17 .00 % 208.00
208 208 0
41 202 .00 % 272.41
146 412 28
42 205,231 3.54 % 611.82 164
32,748 0
50 480 .01 % 242.00
242 242 0
57 6 .00 % 116.00
116 116 0
60 108,710 1.88 % 413.66 330
4,235 0
61 58,515 1.01 % 1,274.90 282
32,298 0
62 6,932 .12 % 190.57
188 228 0
64 17,803 .31 % 458.00
458 458 0
65 20,529 .35 % 371.41 282
16,223 0
66 42,178 .73 % 1,768.97 287
22,983 0
70 192 .00 % 1,562.00 164
2,960 56
71 96 .00 % 1,752.00 1,752
1,752 28
72 5,858 .10 % 1,726.76 1,076
22,668 1,710
73 96 .00 % 19,712.00 19,712
19,712 28
74 2,598 .04 % 17,375.28 364
32,720 762
75 672 .01 % 264.00
264 264 196
76 25,440 .44 % 217.92
216 344 7,420
77 96 .00 % 9,255.00 1,120
24,000 28
78 192 .00 % 9,331.62 1,888
28,256 56
80 251,764 4.35 % 257.25 180
3,775 0
Development:
RECORD RECORDS PERCENT AVG. RECORD MIN. RECORD MAX.
RECORD RECORDS
TYPE READ OF TOTAL LENGTH LENGTH
LENGTH WRITTEN
2 13 .00 % 18.00
18 18 1
3 13 .00 % 18.00
18 18 1
4 18,956 1.65 % 215.00
215 215 0
5 3,303 .29 % 152.99
145 160 0
14 107,217 9.33 % 422.56 318
1,316 0
15 85,273 7.42 % 371.80
318 408 0
16 4,690 .41 % 792.03 592
2,296 0
17 15,559 1.35 % 100.00
100 100 0
18 197 .02 % 144.00
144 144 0
19 1,036 .09 % 72.00
72 72 0
20 4,156 .36 % 99.04
91 106 0
21 321 .03 % 88.00
88 88 0
23 24 .00 % 258.00
258 258 0
26 797 .07 % 446.80
442 457 0
30 103,273 8.99 % 14,642.36 398
32,750 0
34 113 .01 % 215.00
215 215 0
35 113 .01 % 149.89
148 150 0
38 13 .00 % 208.00
208 208 0
41 1,618 .14 % 161.78
146 412 0
42 138,707 12.07 % 586.35 140
32,748 0
50 288 .03 % 242.00
242 242 0
57 1 .00 % 116.00
116 116 0
60 50,775 4.42 % 434.73 334
2,741 0
61 32,016 2.79 % 389.24 282
10,968 0
62 4,806 .42 % 189.03
188 218 0
64 11,167 .97 % 458.00
458 458 0
65 55,424 4.82 % 863.79 282
5,473 0
66 3,601 .31 % 467.23 285
8,208 0
70 192 .02 % 1,562.00 164
2,960 0
71 96 .01 % 1,752.00 1,752
1,752 0
72 5,762 .50 % 1,742.16 1,076
22,668 0
73 96 .01 % 19,712.00 19,712
19,712 0
74 2,502 .22 % 17,938.05 364
32,720 0
75 768 .07 % 264.00
264 264 0
76 25,440 2.21 % 217.93
216 344 0
77 96 .01 % 9,293.33 1,280
25,120 0
78 192 .02 % 8,289.00 1,888
26,432 0
80 225,219 19.60 % 269.38 180
3,775 0
--
Cobe Xu
Best Regards
-----------------------------------------------------------
zOS Performance & Capacity Analyst
E2E Performance Analyst
Email: cob...@gmail.com
-----------------------------------------------------------
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Vernooij, CP - SPLXM
Check the SMFPRMxx members of both systems for differences in the DDCONS
parameter. This consolidates I/O sections, but is usually disabled
because of the large CPU costs and elapsetime of the consolidation,
mostly a problem for DB2.
Kees.
"Cobe Xu" <cob...@GMAIL.COM> wrote in message
news:<232683dd0912161945v321...@mail.gmail.com>...
**********************************************************************
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286
**********************************************************************
Staller, Allan
...This consolidates I/O sections, but is usually disabled
because of the large CPU costs and elapsetime of the consolidation,
mostly a problem for DB2.
Also DFHSM is notable for this same situation.
Cobe Xu
I did check SMF options, yep they're different. And it make sense to me.
--
Cobe Xu
Best Regards
-----------------------------------------------------------
zOS Performance & Capacity Analyst
E2E Performance Analyst
Email: cob...@gmail.com
-----------------------------------------------------------
----------------------------------------------------------------------
Barry Merrill
SAR job (a SYSOUT processing subsystem) was cancelled, the CPU went to
100% busy for 30-60 minutes. Instruction traces found the "loop" was in
DD Consolidation. SAR dynamically allocates a DD for each SYSOUT file
it processes; by the end of the week that step had over 75,000 DD
entries! DD consolidation reads the first DD segment, scans the
remaining 74,999 segments for a match, reads the second and scans the
remaining 74,998 for a match, etc. etc., etc., all at DPRTY=FE! In
response to Diane's discovery, Bill Richardson, IBM SMF Development,
subsequently provided a new SMF option, DDCONS(NO), specified in
SYS1.PARMLIB(SMFPRMxx), so that you can disable this very unwise (in my
opinion) algorithm, and thereby eliminate its wasted CPITCBTM and CPISRBTM
(MXG names for SMF30ICU and SMF30ISB, the "Initiator" CPU time that
occurs before Step Program Load and after Step Program Termination).
All of those empty SYSOUT DD segments can now be removed in z/OS 1.10
with the EMPTYEXCPSEC(SUPPRESS) option:
1. APAR Identifier OA29582 adds new EMPTYEXCPSEC(SUPPRESS) option in
SYS1.PARMLIB to suppress all empty EXCP entries.
The option prevents the creation of null segments in SMF 30 records
for SMS Candidate Volumes, and could significantly reduce the size
of your step and job termination records, especially if your site
has a default of (SYSDA,5) for every allocation!!
The MVS Initialization and Tuning Reference, under the SMFPRMxx
parmlib parameter definitions, EMPTYEXCPSEC:
SUPRESS specifies that the system suppress the creation of empty
EXCP sections. Empty sections can be the result of non-dataset
allocations, such as DD DUMMY, or for spool file allocations
(i.e., SYSIN, SYSOUT JES DDs), or for non-allocated candidate
volumes in the SMS storage group.
One MICS site reported a 28% reduction in CPU time with removal of
all of their empty EXCP segments.
New EMPTYEXCPSEC option in PARMLIB is z/OS 1.10 only.
While EMPTYEXCPSEC option is documented in the z/OS 1.9 SMF
manual in Section 13.34.2.7 (Execute Channel Program (EXCP)
Section) of z/OS MVS System Management Facilities (SMF) Document
SA22-7630-16, for z/OS 1.9, testing on a z/OS 1.9 system
resulted in
IEE945I UNRECOGNIZABLE OPTION 'EMPTYEXCPSEC' IN PARMLIB INPUT
IEE947I '/* DEFAULT RETRY */
EMPTYEXCPSEC(SUPPRESS)' SKIPPED DUE TO PREVIOUS ERROR
IBM has confirmed that the option only exists in z/OS 1.10, where
it is listed in the Release Guide as a 1.10 enhancement
Barry Merrill
GILES,Peter
Worth a try ?
Peter Giles
Systems Programmer
ITSG
DEEWR
C14BR2
Level 2, 14 Brindabella Cct, Pialligo ACT 2609
Tel +61 2 6121 8081
Fax +61 2 6276 4908
Mob 0411 074 964
peter...@deewr.gov.au
Barry Merrill
Notice:
The information contained in this email message and any attached files may be confidential information, and may also be the subject of legal professional privilege. If you are not the intended recipient any use, disclosure or copying of this email is unauthorised. If you received this email in error, please notify the DEEWR Service Desk by calling (02) 6240 9999 and delete all copies of this transmission together with any attachments.
Cobe Xu
very useful.
However, I'm a little bit confuced when I sum up CPITCBTM & CPISRBTM by date
for the 2 lpars (one is DDCONS=YES, the other is NO), the result is not what
I expected to see:
1. The lpar with DDCONS=NO, then total CPITCBTM+CPISRBTM approachs
0. because all the jobs should bypass DD consolidations.
But what I got is, still many many jobs spend a few seconds on
CPITCBTM. So, how to explain?
2. The lpar with DDCONS=YES, should have much bigger value for
CPITCBTM+CPISRBTM than the other lpar.
But in fact the difference varies from 100 seconds to 350 seconds per
day.
regarding the EMPTYEXCPSEC(SUPPRESS) , we're still in 1.9.
--
Cobe Xu
Best Regards
-----------------------------------------------------------
zOS Performance & Capacity Analyst
E2E Performance Analyst
Email: cob...@gmail.com
-----------------------------------------------------------
----------------------------------------------------------------------
Barry Merrill
The "Initiator" TCB/SRB CPU time is not only due to DDCONS,
but is all of the CPU time that occurs between Initiation
and Program Load time, which includes DSENQ time,
the cost of execution of your SMS Allocation Rules,
HSM Recalls, VAM product, and SMS Trace CPU time,
PLUS
the CPU time after the Loaded Program has terminated,
which includes the DDCONS CPU TIME and Catalog CPU
time.
And, there may be other contributors to those CPU times.
2. But the original issue of size of 30s can also be impacted
by your choice of INTERVAL and DETAIL options in SMFPRMxx:
10. No EXCP data for type 30 subtypes 4 and 5 from STCs.
SMF Type 30 subtypes 4 and 5 for STCs (Started Tasks) do not contain an
EXCP segment when INTERVAL and NODETAIL is specified in SMFPRMnn member
of SYS1.PARMLIB, even though the EXCP segment does exist in subtypes 2
and 3 (the interval records). This is documented under the DETAIL
parameter in Initialization and Tuning (but not mentioned in SMF
Manual). What is not documented is that NOINTERVAL and NODETAIL options
DO create EXCP segment for STCs in subtypes 4 and 5! Thus a site which
had not specified INTERVAL and had NODETAIL by default was recording
EXCP counts in STC step and step termination records, but when the site
decided to record INTERVAL data, the STC EXCP counts all became zero!
The moral: ALWAYS specify DETAIL for STCs so that EXCP counts are in
the subtype 4 and 5 records, no matter what the INTERVAL/NOINTERVAL
parameter specifies. Originally printed in MXG NEWSLETTER SIXTEEN.
26Apr02 revision to the preceding "ALWAYS specify DETAIL":
- IBM Information APAR II07124 discusses why you might need to
specify NODETAIL for your STC's: When DETAIL is specified, the DD
and EXCP information will be stored in 32K memory blocks in SP230,
and those blocks (in virtual storage) are kept for the entire life
of the address space. For an STC like DBM1, which can have 10,000
DDs, its SP230 can grow and run out of private area storage, both
high and low, requiring a restart of the DB2 system to clear the
Sub Pool. Instead, with NODETAIL, the DD information is only kept
for each interval record, i.e., in PDB.SMFINTRV, so the data is
available in SMF, and DBM1's SubPool 230 does not grow over time,
so you don't have to stop and restart your DB2 subsystem.
- That APAR also recommends DDCONS=NO, a parameter that was created
by IBM as a result of an MXG user's discovery of the problem it
corrects, so MXG has always recommended DDCONS=NO be specified.
- Specifying NODETAIL for STCs has no direct impact on MXG logic.
Your STC observations in PDB.JOBS/PDB.STEPS will have zero for the
EXCP/IOTM variables, which might affect your chargeback for STCs,
but STCs are usually an internal charge; furthermore, only those
STCs that are terminated normally (created subtype 4/5) could have
been billed for STC EXCP counts. But the EXCP/IOTM variables for
STCs will exist the PDB.SMFINTRV dataset for each interval, even
with NODETAIL, as long as INTERVAL is enabled to write subtype 2/3
records, (and MXG member IMACINTV was enabled to populate TYPE30_V
and PDB.SMFINTRV datasets). And with a large value for SPINCNT in
your MXG member IMACSPIN, dataset PDB.SMFINTRV will contain the
ACCOUNTn and SACCTn accounting fields for the STC, so those EXCP
counts for your STCs can still be charged back with PDB.SMFINTRV.
12May03 addition:
- To keep DB2 "up forever", you do NOT have to turn off SMF interval
recording, which is a mis-reading of that APAR. As long as both
NODETAIL and DDCONS=NO are specified, the NODETAIL eliminates the
SP230 growth issue, and DDCONS=NO eliminates the CPU spike, so you
can continue to write SMF type 30 interval records for your DB2
that is designed to "never end".
Mark Zelden
<snip>
> The moral: ALWAYS specify DETAIL for STCs so that EXCP counts are in
> the subtype 4 and 5 records, no matter what the INTERVAL/NOINTERVAL
> parameter specifies.
>
Not if you want to keep your large (FSVO "large") DB2 subsystems up
and running. DETAIL with INTERVAL can cause a problem with running
out of virtual storage (I haven't seen the problem with other long running
STCs). Read your own notes below which explains the storage creep
issue.
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html