Rob,
When you think about it, the collection size is going to be a factor of how
busy the partition is with what types of transactions, and how much data you
chose to collect so the answer to your question is: "It depends....."
Keep in mind since you're a multi partition/machine shop, you could collect
the data on each production partition keep it there for one or two days and
create a "performance" partition ( completely virtual ) where you keep the
collections all together. Use a library name to store the collection
objects/performance files that matches the name of the partition. Do the
analysis there. That way you keep the production partitions clear of
performance data and don't impact that partition with the SQL/Processing to
do the analysis.
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
rob@xxxxxxxxx
Sent: Monday, April 13, 2015 1:51 PM
To: Midrange Systems Technical Discussion
Subject: RE: Performance data
Since I just reset everything I had to query QUSRSYS.QAEZDISK (from
RTVDSKINF).
Back when we did 15 minutes, and only kept 2 days I was seeing
Object Object Object Object
Library Type Size
QMPGDATA Q098000102 MGTCOL 10,942,779,392
QMPGDATA Q099000102 MGTCOL 1,809,330,176
QMPGDATA QAPMJOBMI FILE 1,353,711,616
QMPGDATA QAPMJOBWT FILE 535,486,464
QPFRDATA QAPTTRCJ FILE 328,556,544
QMPGDATA QAPMJOBOS FILE 286,281,728
QMPGDATA QAPMJOBWTG FILE 158,642,176
QMPGDATA QAPMJOBL FILE 57,442,304
QMPGDATA QAPMDISK FILE 4,202,496
QMPGDATA QAPMSYSL FILE 4,063,232
QMPGDATA QAPMHTTPD FILE 3,203,072
QMPGDATA QAPMDISKRB FILE 3,039,232
QMPGDATA QAPMJSUM FILE 1,941,504
QMPGDATA QAPMJVM FILE 1,716,224
QMPGDATA QAPMPOOLT FILE 1,703,936
QMPGDATA QAPMPOOLL FILE 1,105,920
QMPGDATA QAPMAPPN FILE 905,216
QMPGDATA QAPMJOBSR FILE 811,008
...
Granted, in the grand scheme of things what is "significant" is in the eye
of the beholder.
The volume of performance data isn't dependent on the number of transactions
or anything, correct? Simply time interval and length of retention?
PRTDSKINF RPTTYPE(*LIB)
% of Size in
Library Owner Disk 1000 bytes
#MXJRN MIMIXOWN 38.90 2132138975.2
ERPLXF SSA 6.56 359586054.1
QGPL QSYS 2.57 140651675.6
ERPLXSAVF SSA 1.97 108070228.0
ERPMRP SSA 1.65 90212122.6
GDIDIVF SSA 1.40 76955828.2
YEAREND SSA 1.05 57758679.0
ERPLXUSRF SSA .94 51337199.6
GDITOLF SSA .71 38691659.8
ROUTINES ROB .69 37898330.1
ERPLXFESP DARREN .66 36359241.7
#MXJRN@R MIMIXOWN .48 26169372.7
ERPLXARCF SSA .40 21705097.2
MKSARCH ROB .35 19065094.1
MGR1499099 SYSGENPGMR .33 18276352.0
QUSRBRM QBRMS .32 17477861.4
MIMIX MIMIXOWN .32 17285832.7
CLOCFILE00 QSECOFR .29 15769456.6
QMPGDATA SYSGENPGMR .28 15178330.1
...
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: "Jim Oberholtzer" <midrangel@xxxxxxxxxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 04/13/2015 01:51 PM
Subject: RE: Performance data
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
Rob,
I'll strongly argue that even 7 days is not sufficient data to establish a
trend or find performance issues. If you have a process that only runs
once
a week, you don't have any comparison to see if the performance of that
function changed week to week. Month end processes present a similar
problem. Really I would like 90 days of collections stored on line but
nearly every customer I have balks at using that much storage for
performance collections so I get back to the 14/21 day retentions.
Keep as many days as you want, in the end it only matters if you run into
a
program change, or other benchmark that you'll need the data in the event
of
an issue. Now, if your backing the data up to a separate tape and
actually
keep it all, that's the real desire, since we can just restore what we
need
and to the evaluation.
As to the suggestion earlier to change the collection interval to 5
minutes,
I would agree that's a better number if you are zeroing in on a problem,
but
it also increases the size of the collections by about double. Again they
are small, but for some reason folks get excited about the amount of
storage
they use.
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
rob@xxxxxxxxx
Sent: Monday, April 13, 2015 12:37 PM
To: Midrange Systems Technical Discussion
Subject: RE: Performance data
I just ran the following on all lpars:
ENDPFRCOL FRCCOLEND(*YES)
CFGPFRCOL INTERVAL(15.00) LIB(QPFRDATA) DFTCOLPRF(*STANDARDP)
CYCTIME(000000) CYCITV(24) RETPERIOD(7 *DAYS) CRTDBF(*YES) wrklib qmpg*
and
deleted QMPGDATA wrklib qpfr* and deleted upgrade versions STRPFRCOL
I guess 10 days or more makes sense. Let's say you come in on Monday and
noticed your Friday job lasted a lot longer than normal. If you did 10
days
you'd still have that day to look at comparisons.
I think 5 days is the new default. That's what it was on a newer lpar.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 04/13/2015 01:18 PM
Subject: RE: Performance data
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
I would also change the interval default from 15 to 5.
I keep 10 days raw data, I have compressed data back to 2006 with MPG.
Also, whenever an i5/OS upgrade is done, by default, you will end up with
a QPFRD... Down level files from library QMPGDATA
This is in the i5/OS upgrade instructions.
QPFRD61001 QSYS 1.41 40234610.7 05/06/12 Down level
files from library QMPGDATA
29. If you use the IBM Performance Management for Power Systems(tm)
function,
the Collection Services tool, or the Performance Tools licensed program
and
you collected data before installing your new release, you need to perform
an
action to enable the collecting of performance data to continue.
You have the following choices regarding how to handle your performance
data from the prior release:
v Convert the data.
Use the Convert Performance Collection (CVTPFRCOL) command to
convert the data in the collection library. This command supports data
conversion for Collection Services, PEX, Job Watcher, and Disk Watcher
file
collections.
v Automatic data collection support. When Collection Services is started
at
IPL, a performance library for the prior release files is created.
Collection
Service database files are moved to that library. This action allows new
files
to be created and preserves the existing data files from the previous
release.
You should be aware of the following items:
- The library name that is created is QPFRDvrmnn, where vrm is the
current version, release, and modification and nn is a unique sequence
number starting with 01, for example, QPFRD52001.
96 IBM i: IBM i and related software Installing, upgrading, or deleting
IBM i and related software
- The library is created with *EXCLUDE public authority. The library is
owned by the QSYS user profile, and the owner of the original library is
given *ALL authority.
- All QAPMxxxx files are moved.
- If you do not want to keep the data from the previous release, you can
delete the QPFRDvrmnn library with the Delete Library (DLTLIB)
command (DLTLIB qpfrdvrmnn)
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim
Oberholtzer
Sent: Monday, April 13, 2015 12:41 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Performance data
Yes.
I would change the library to one of your choosing (QPFRDATA and QMPGDATA
are/were the defaults) you can store performance data anywhere you want
really.
I would turn create the database files off. You can create the
performance data files any time from the collection object so no need to
have them unless you're going to use them.
Personally I urge everyone to keep at least 14 days of collection objects,
21 or 31 are preferred numbers if there is sufficient space available. The
collection objects don't take a great deal of space, but some folks get
excited about it.
Also I strongly urge folks to back up the performance data on a separate
back up appending to a tape kept just for performance data. Once a week
is sufficient. That way your performance data is backed up if you ever
need it, and you can exclude that data from your normal backups since
performance
data is not needed for a recovery. In a recovery situation do you really
care about performance data, I suspect not, so don't spend the time to
back it up or recover it during the emergency. You can recover it later
if it's really needed.
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
rob@xxxxxxxxx
Sent: Monday, April 13, 2015 11:17 AM
To: Midrange Systems Technical Discussion
Subject: RE: Performance data
Via this?
Configure Perf Collection (CFGPFRCOL)
Default interval . . . . . . . . 15.00
Collection library . . . . . . . QMPGDATA
Default collection profile . . . *STANDARDP
Cycle time . . . . . . . . . . . 000100
Cycle interval . . . . . . . . . 24
Collection retention period:
Number of units . . . . . . . 00024
Unit of time . . . . . . . . . *HOURS
Create database files . . . . . *YES
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: "Jim Oberholtzer" <midrangel@xxxxxxxxxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 04/13/2015 12:10 PM
Subject: RE: Performance data
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
Rob,
Do you only keep two days of management collection objects? (I really
like
to see folks keep at least 14 days worth, 21 days are better) It sounds
like collection services is set up to put the management collection
objects in QMPGDATA rather than QPFRDATA. Also clearly you don't create
the performance data very often or at all. (a good thing if you don't need
the files for a performance investigation)
QPFR is the performance tools licensed program product library, I would
not mess with it.
QPFRDATA: I would not clear since that's really an IBM supplied library.
QMPGDATA could be removed as long as collection services is updated to use
QPFRDATA.
QPFRD71001 is a library of user creation not by IBM/MPG so clobber away if
you wish.
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
rob@xxxxxxxxx
Sent: Monday, April 13, 2015 10:47 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Performance data
I have these libraries on my system:
QMPGDATA
QPFR
QPFRDATA
QPFRD71001
QPFR has a bunch of programs in it.
QPFRDATA only has 4 files in it with a blank last used date. Change date
is from our system migration.
QPFRD71001 only has a few files in it created back in 09 or 10 with blank
last used dates and change dates from our system migration. Assuming this
is performance data prior to when that system upgraded to 7.1.
QMPGDATA has numerous data queues in it created back in 09 or 10, all with
blank last used dates and the change dates are from our system migration.
It does, however, have several active files. Along with those two huge
active *MGTCOL's.
I realize that everyone's system may differ. Our systems that have been
around forever have an active QMPGDATA and dormant QPFRD* libraries. Our
systems that started fresh with 7.2 do not have QMPGDATA and have an
active QPFRDATA.
Should I delete QPFRD71001 (been a long time)?
Should I clear QPFRDATA on the top system?
Should I delete the data queues from QMPGDATA that were created 2 or more
years ago and have blank last used dates?
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
