PerfKit will keep, by default, 3 generations for all of the detailed log files
that contain data for single days, where yesterday's files will have a filetype
ending with a '1', and the files created the day before yesterday will have a
'2' appended. All of the filetype2 files will be automatically erased, and the
other generations renamed, at midnight.
The FCXRENAM EXEC can be used to keep less generations (by erasing one or two
additional generations), or to keep more of them by renaming the filetype2
files to some other filetype, e.g. filetype3, that PerfKit will leave alone.
The HISTSUM and FCXTREND summary files are intended to hold performance data
for longer periods, as input for trend analysis and capacity planning. No
automatic pruning mechanism is implemented.
- HISTSUM files only contain overall performance data for the system and so
don't need too much disk space even when keeping data for longer periods.
I would recommend to keep data for at least one or two years. Just use the
command 'COPYFILE ACUM HISTSUM A = = = (FROM nnnn REPLACE'
to prune it once every few months and get rid of the first nnnn records.
- FCXTREND files can contain a lot more information, including also data
for each individual user, I/O device, channel, etc.
Depending on the records created (see definitions made in control file
FCONX TRENDREC) and on the number of trend periods defined for
each day, the amount of space needed per day will vary. But a LOT of
disk space may be filled if you let trend records be built for all your DASD,
and if you have access to a large DASD farm.
The recommendation is
1. Don't create any records that you won't need (e.g. DASD records
for disks belonging to other LPARs), i.e. make sure the definitions
in FCONX TRENDREC are adapted to your needs.
2. If you want to keep trend data for longer periods (several months)
better define an additional large archive minidisk and copy/append
the file on the A-disk to the file on the archive disk, then erase the
file
on the A-disk.
I've also written an FCXTREND package that allows pruning an FCXTREND
files based on individual expiration dates for different record types, i.e.
it can delete records with DASD and user details relatively early but keep
more general data longer (based on specifications in a control file).
Contact me offline if you want a copy.
Eginhard Jaeger
----- Original Message -----
From: Austin, Alyce (CIV)
To: [email protected]
Sent: Wednesday, August 15, 2007 7:16 PM
Subject: Re: PERFSVM cleanup
Hi Kris,
Thanks for your reply.but, I didn't see your execs. Did you forget to attach
them?
I guess the CONLOG and HISTLOG files get cleaned up by some other process
since
I did see them specify in the FCONX $PROFILE file on PERFSVM's 191 disk.
Thanks again,
Alyce
------------------------------------------------------------------------------
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of
Kris Buelens
Sent: Monday, August 13, 2007 11:35 PM
To: [email protected]
Subject: Re: PERFSVM cleanup
Here my exec. As one can see, it is meant to be extended at some later day.
At this time, it checks the userid, to be either KRIS, VMPRF, or TSLARUN (the
last two are RxServer based servers that we use for VMUTIL-like work).
---------- Forwarded message ----------
From: Kris Buelens <[EMAIL PROTECTED]>
Date: 14 aug. 2007 09:25
Subject: Re:
To: The IBM z/VM Operating System <[email protected]>
CONLOG and HISTLOG files are cleaned up automatically, additionally you can
code an FCXRENAM EXEC that the PTK will execute, and where you can cleanup
other things, or create extra archives. Apart from that, no automatic cleanup
is done and when the A-disk gets full, it remains full. But, PERFSVM remains
active, you will still be able to look at real-time performance data.
I've got an EXEC that runs in one of my other servers that will collect more
CONLOG files in SFS, useful for debugging. It also keeps an eye on the 191
disk of PERFSVM and removes the FCXTREND file when the disk becomes more than
x% full. I'll send it to you, it should run in a server that is authorized in
the PTK, or you can change it to become FCXRENAM. As server you could use
VMUTIL, for example based on my RxServer package.
2007/8/14, Alyce Austin <[EMAIL PROTECTED]>:
Hello,
I notice that PERFSVM A DISK fills up rather quickly.
Does it automatically "role-over" when it gets to a certain
percentage? If not, what is the best way to "clean it up"?
Which files are OK to delete and still keep it running?
Thanks for your help,
Alyce
--
Kris Buelens,
IBM Belgium, VM customer support
