Our MONDCSS grew, perhaps too large, while fighting this type message a long
time ago. Once the problem was resolved, we didn't attempt to back off the
changes we'd made, and the large size doesn't seem to hurt anything at the
moment. I know that ultimately, making the segment larger was not the answer
to the problem at the time, either.

Also, Mr. Nunsford says hello.

-- 
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 12:57 PM, "Eginhard Jaeger" <e.jae...@ch.inter.net> wrote:

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

Reply via email to