Also, for consideration, might there also be "frequency of reference", such as security (ACF2, RACF, etc.) and/or DB2 TRACE (SMF 102 types) -- both of which may require near real-time access directly from the SMF Logstream, as well as after the SMF historical offload occurs?
Maintaining separate SMF recording/offloading by SMF type provides the opportunity for SMS-managed historical data-capture, as a retention-limit. For a client/site we support, SMF Logstreams are defined/managed by CA SMF DIRECTOR using zEDC (8-to-1 compression typical) with DFHSM-managed historical (ML0->ML2 directly) data, for up to 5 years -- again, based on SMF type, as follows: - DFLT -- all types other than below mentioned, - CICS / SMFT110 -- includes both CICS CMF and STATISTICS, - DB2 / T101 -- DB2 ACCOUNTING, - DB2 / T102 -- DB2 TRACE, - ACF2 -- security logging events, - WAS / SMFT120 -- includes WAS and WAS/ODM subtypes, - MQ / SMFT116 -- excludes SMF Types 115 and 117 (IIB), - IDMS / T254 And with CA SMF DIRECTOR software deployed, one need not know where an SMF type / recorded-date/time resides, only specify the EXTRACT statement with the system (or ALL), type/subtype, date/date/time-range) and the software takes care of finding the requested historical data (accomplished via dynamic allocation, no JCL-DD coding). SMF historical data retention limits are also managed by the software. The software also controls awareness with BEFORE/AFTER MAN-to-Logstream migration, again not requiring the end-user to know where to find SMF type/subtype, etc. Very effective with simplifying and streamlining SMF data management, while maintaining auditability and access-limit compliance -- tracking what SMF data was recorded, offloaded, when, and who has approved access (via program-limitation with security-rules). Regards, Scott Barry SBBWorks, Inc. On Fri, 9 Feb 2018 13:16:59 +0000, Richards, Robert B. <robert.richa...@opm.gov> wrote: >Scott, > >I am the OP. > >I definitely appreciate your comments (and everyone else's too), but no one >was commented on the other half of my questions. > >At what point or percentage (records written/space used) would it be advisable >to split out 92s, 99s, 120s into their own logstreams? Right now they are all >in Default. A coworker tested turning on 120s in WebSphere for an hour and >then grew it into an estimated 2 million records that would use 48% of the >space after 8 hours. Not sure if that was one WAS server or more, but that >certainly got his attention. > >I realize YMMV, but am canvassing for real world expeeiences here. > >Bob > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Scott Chapman >Sent: Friday, February 09, 2018 7:31 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: SMF advice on additional logstreams > >Remember when looking at SMF volume, record counts are interesting, but the >bigger issue is the number of bytes written. > >We (Peter Enrico and myself) recommend collecting at least 99 subtypes 6, 10, >11, 12, and 14. > >6 is especially important as it's the summary service class period information >(every 10 seconds) >10 is dynamic processor speed changes, which you hopefully don't see >11 is for Group Capacity limits, and is written every 5 minutes >12 is HiperDispatch interval (2 second) data which can show you utilization >information on a 2 second basis which can be quite interesting >14 is HiperDispatch topology data written every 5 minutes or when a change >occurs > >The 6s and 12s are in fact high volume in terms of the number of records, but >the records themselves are relatively short. In terms of bytes, from what I've >seen the subtype 6 is somewhere between 40 and 100 MB of additional SMF data >per system per day. Subtype 12 seems to run around 40 to 50MB. I expect that's >not noticeable in most environments. Indeed, the type 30s can easily be more >data than that. Not to mention the 101s, 110s, and 120s. I actually have a >slide on this in an upcoming conference presentation. > >The other 99 subtypes are used less often and some can be more voluminous than >the 6 summary records. If you don't want to record those subtypes all the >time, I'm ok with that. But OTOH, if you need them to do a deep dive on WLM to >try to understand why things worked the way they did, then having them handy >is better than having to turn them on and recreate the issue. We don't >formally recommend people keep them enabled, but if it was me, I'd probably >keep at least most of them enabled. > >The 92s are file system information. The subtypes 10 and 11 are written every >time a file is opened/closed. In large Websphere Application Server >environments I've seen these being very voluminous. I haven't looked at them >lately, but my recollection from quite some time ago is that directory >traversal (at least in the HFS file systems) triggered these records as well. >I've seen the 92s in such an environment being much more voluminous than the >99s. In that environment, I did have the 92s turned off because of this. > >There are relatively new subtypes (at least 50-59) in the 92s, that may be why >the OP is seeing more 92s. It looks like possibly useful information if you're >tuning zFS performance, but I personally haven't spent any time yet >investigating them. > > >Scott Chapman > > >On Thu, 8 Feb 2018 16717:47 +0000, Allan Staller <allan.stal...@hcl.com> wrote: > >>Not sure about SMF92, but SMF99 are "WLM decision records". >> >>Yes they are large volume, but somewhat indispensable. >> >>Generally when there is a WLM problem it is extremely difficult or impossible >>to reproduce. >>If the SMF99's are not available "during the problem" it is virtually >>impossible to debug. >> >>IMO, SMF99's should be recorded. I know Cheryl Watson and others may >>disagree. >> >>My US$ $0.02 worth, > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, send email to >lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
