Re: Controlling MONWRITE and the size of its 191 disk
Rob, no apology necessary and I hope I did not come across as wanting to start or play in a 'mine vs yours' game or make readers think that. While it is true that the history data files do not contain the same detail as raw mondata, they are worthwhile to review and investigate if one is not familar with them...to see if what you are after can be done via the History files rather than saving the entire raw mondata filesaka: no need to boil the ocean when all I am interested in are the Great Lakes (sorry, hometown joke)!! There are just a number of things we can do with the Perfkit that we could not do with VMPRF...one being the processing of our own generated History data files, and that wa s one of the main points I was trying to make. Thanks for the discussion/et c. Best Regards, Roger Lunsford z/VM CPL2 and Perfkit L2/L3
Re: Controlling MONWRITE and the size of its 191 disk
The PERFKIT can create HISTORY DATA files, which can be looked at as condensed monitor data files. The PERFKIT can also process these data files via the PERFKIT MENU OPTION 32 HISTORY DATA FILES. Within the ACUM HISTSUM and the MMDD HISTLOG I can see the CPU Utilization on each monitor interval. I fI am interested in a specific user(s), I then simply BENCHMRK these users, and can also get the same type of condensed monitor records as well...utilizing MUCH LESS disk space than RAW CP Mondata. I would advise to check this out. Best Regards, Roger Lunsford z/VM CPL2, Perfkit L2/L3
Re: Controlling MONWRITE and the size of its 191 disk
Is there any specific reason why you would want to first collect the monitor data using MONWRITE, and only then run the analysis in batch mode? One would usually let PerfKit collect the data in real time and just let it print whatever reports you're interested in for the periods you want the data for. As you've found the size of the monitor data file can grow fast, especially if you have lots of DASD and/or users. If you run PerfKit the MONDATA report will tell you which record types account for most of the space. Basically you can reduce the space requirements by - Disabling monitor domains that are not needed for the reports you're interested in. For just general CPU and storage reports you only need data from the SYSTEM and STORAGE sample domains. Be aware, however, that you cannot disable monitor domains just for MONWRITE's benefit: if you also have a monitor running in real time mode, it will be left with the same reduced set of monitor data, and so won't be able to report on users' or DASD performance once you disabled the USER and I/O sample domains .. - Since only sample data is needed, you can further reduce the number of records collected by increasing the length of the monitor sample interval from the default 60 seconds to 5 or 10 minutes. This will reduce the granularity of the data and is not usually recommended if you need to analyze a performance problem, but it will not impair the accuracy of the data and so is ok if you just need statistical information about system load. But again: why not just let PerfKit collect and print the data in real time mode? Eginhard Jaeger - Original Message - From: Hamilton, Brian To: IBMVM@LISTSERV.UARK.EDU Sent: Thursday, November 01, 2007 3:01 PM Subject: Controlling MONWRITE and the size of its 191 disk Hello, I'm using Performance toolkit and would like to use the batch interface. I've set up the Performance toolkit batch commands however my problem now is the MONITOR DATA file. The size of the file grows quickly, it about 1 hour the file consumes 90 cyls.. My goal is to collect the data on a ongoing basis, at least for a few days. Any help on setting the size of MONWRITE's 191 disk and a method to keep a few days worth of data would be appreciated. For now I want to monitor CPU and Storage usage. Thanks Brian
Re: Controlling MONWRITE and the size of its 191 disk
Regarding the, problem of perhaps wishing to only collect a subset of the monitor records for, MONWRITE / post-processing activities while still needing a fuller set of records for realtime monitoring, it is really a trivial exercise to write a PIPE that collects MONITOR records ( a la MONWRITE) and, of course, it would be equally trivial to code a filter into that pipe to drop the records that were only of, real time interes t. While I completely understand that new folks on the block may have other priorities I'm always bemused when I see folk struggling with the vanilla data collection mechanisms for accounting, monitoring and the such when it's so easy use PIPE to roll a customised collector that fits your exact needs. (Nowadays, the vanilla tools are, sufficient unto my needs - but this has not always been the case and, of course, Melinda's Plumbing Papers contain discussion regarding the collection of accounting data - most of which reads straight across into the monitor data collection context.) Jeff
Re: Controlling MONWRITE and the size of its 191 disk
On 11/1/07, Hamilton, Brian [EMAIL PROTECTED] wrote: The size of the file grows quickly, it about 1 hour the file consumes 90 cyls…. You're right. Raw data files are huge. One option is to make the interval larger, but this also very much limits the detail you can see in your real time data. If you don't care about I/O performance, you could disable that domain and save some more. You probably have already disabled seeks and scheduler data. An alternative product I know of uses a condensed format for performance data to save disk space, disk I/O and processing time. Just checked: and on a pretty serious system we need 10 cyls per hour. This includes Linux process data of a few systems, and a lot of devices. The data is still with 1 minute granularity to do analysis and reporting. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
Re: Controlling MONWRITE and the size of its 191 disk
Thanks, can you let me know what settings are active for Monitor. Q MONITOR should display this. Thanks -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij Sent: Thursday, November 01, 2007 10:22 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Controlling MONWRITE and the size of its 191 disk On 11/1/07, Hamilton, Brian [EMAIL PROTECTED] wrote: The size of the file grows quickly, it about 1 hour the file consumes 90 cyls You're right. Raw data files are huge. One option is to make the interval larger, but this also very much limits the detail you can see in your real time data. If you don't care about I/O performance, you could disable that domain and save some more. You probably have already disabled seeks and scheduler data. An alternative product I know of uses a condensed format for performance data to save disk space, disk I/O and processing time. Just checked: and on a pretty serious system we need 10 cyls per hour. This includes Linux process data of a few systems, and a lot of devices. The data is still with 1 minute granularity to do analysis and reporting. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
