Hi Bill; We have 295 CP volumes (3390 mod 27) shared between the two LPAR's, running CSE. There are an additional 15,652 volumes owned by z/OS, which we keep offline to z/VM.
We run a script in AUTOLOG1 which goes through the list of volumes and makes the decision for each if it should stay online to z/VM, and takes action to set things into their "normal" state. ckofflin 0 errors 295 CP OWNED or SYSTEM disks skipped 0 PAV Aliases skipped 15652 found already offline 0 varied offline Ready; T=0.22/0.31 08:23:27 -- Robert P. Nix Mayo Foundation .~. RO-OE-5-55 200 First Street SW /V\ 507-284-0844 Rochester, MN 55905 /( )\ ----- ^^-^^ "In theory, theory and practice are the same, but in practice, theory and practice are different." On 3/30/10 1:18 PM, "Bill Munson" <[email protected]> wrote: > 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 <[email protected]> > Sent by: The IBM z/VM Operating System <[email protected]> > 03/30/2010 01:57 PM > Please respond to > The IBM z/VM Operating System <[email protected]> > > > To > [email protected] > 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" <[email protected]> >> >> 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. > ****************************************************************************** > **
