Eginhard, Yes it was trial and error - and we made it LARGE enough not to fail again
In our Largest LPAR we have 80 guests running - 52 are LINUX guests. 70 mod27's and 75 mod3's for (paging) and one mod9 the RES pack. we have 5 VM lpars and all lpars can see the other dasd, though not attached to the system, only the dasd for each LPAR is attached to that system, we do not vary off anything but the MVS dasd q monitor MONITOR EVENT ACTIVE BLOCK 4 PARTITION 16384 MONITOR DCSS NAME - MONDCSS CONFIGURATION SIZE 800 LIMIT 1 MINUTES CONFIGURATION AREA IS FREE USERS CONNECTED TO *MONITOR - ESAWRITE LINMON PERFSVM MONITOR SAMPLE ACTIVE INTERVAL 1 MINUTES RATE 1.00 SECONDS MONITOR DCSS NAME - MONDCSS CONFIGURATION SIZE 1500 LIMIT 1 MINUTES CONFIGURATION AREA IS FREE USERS CONNECTED TO *MONITOR - ESAWRITE LINMON PERFSVM munson 201-418-7588 Eginhard Jaeger <e.jae...@ch.inter.net> Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> 03/30/2010 01:57 PM Please respond to The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: [?? Probable Spam] Re: Perfkit SAMPLE CONFIG size too small There is no single 'right' MONDCSS size for all systems: it's about performance, so 'it depends'. The MONDCSS has to be large enough to allow the CP monitor to place all the monitor records you told it to collect in that storage area. Since most users just go and enable whole domains, it's the domains generating the largest number of monitor records that one wants to watch. For sample records that is, on most systems, the I/O domain, where you could end up with tens of thousands of devices already years ago when I still worked with VM. Be aware that the monitor will create a device activity record 3 of 268 bytes and a cache activity record 4 of 264 bytes for each DASD, and they must all fit simultaneously into the MONDCSS, together with all the other monitor records. (And, as mentioned in another append, the default SAMPLE CONFIG size is often too small for so many devices and has to be made larger.) But there's one general rule that has not yet been mentioned in this thread: don't let the MONDCSS overlay the storage of the virtual machine that is doing the data collecting, in this case PerfKit, or it will not be able to use it. While your MONDCSS looks VERY large to me, I'm admittedly out of date as far as current I/O configurations are concerned, and you apparently ended up with it for a good reason, after a trial and error phase with smaller sizes. Can you tell me the number of I/O devices that your VM sees and is collecting data for? Eginhard >----- Original Message ----- >From: "Bill Munson" <william.mun...@bbh.com> > >That does not look like it is large enough. > >here is my definition > >MONDCSS CPDCSS N/A 08000 0FFFF SC R > >It can work for a while but if the segment is not large enough it will >soon fail. *************************** IMPORTANT NOTE*****************************-- The opinions expressed in this message and/or any attachments are those of the author and not necessarily those of Brown Brothers Harriman & Co., its subsidiaries and affiliates ("BBH"). There is no guarantee that this message is either private or confidential, and it may have been altered by unauthorized sources without your or our knowledge. Nothing in the message is capable or intended to create any legally binding obligations on either party and it is not intended to provide legal advice. BBH accepts no responsibility for loss or damage from its use, including damage from virus. ********************************************************************************