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
