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.
********************************************************************************
