Richard,
Nothing unusual will happen at first. As the mod 3s start filling up,
the system will attempt to page preferentially to the mod 9s because their
performance will be better. (The paging subsystem will be able to write
longer blocks of pages to the less full volumes.) In the extreme, you'll
end up paging exclusively to those five volumes.
One hopes you'd resolve the configuration (replace mod 3s with more mod
9s) before reaching that point
Marty
> -----Original Message-----
> From: The IBM z/VM Operating System
> [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard
> Sent: Thursday, November 13, 2008 3:28 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Page Space
>
> What will be the effect, other than having additional space available,
> of adding five mod 9 disks to the existing page farm of 35 mod 3s? Would
> there be a noticeable change in the performance of the paging subsystem?
> (I suspect that any change will be less noticeable than the effects of
> filling both page and spool. :-) )
>
> Regards,
> Richard Schuh
>
>
>
> > -----Original Message-----
> > From: The IBM z/VM Operating System
> > [mailto:[EMAIL PROTECTED] On Behalf Of Barton Robinson
> > Sent: Thursday, November 13, 2008 11:36 AM
> > To: IBMVM@LISTSERV.UARK.EDU
> > Subject: Re: Page Space
> >
> > Do the math.... Number one reason for ONE outage at each new
> > z/linux installation is to fill up page space - guess you
> > were lucky and had some extra spool space (no block paging so
> > slow), so you luckily didn't take the outage - which makes
> > your servers even slower....
> >
> >
> >
> >
> > Schuh, Richard wrote:
> >
> > > Don't presume. 92G real, 10 xstore. All MDC activity is in real,
> > > limited to 384MB. And I do not know the color of the machine :-)
> > >
> > > Regards,
> > > Richard Schuh
> > >
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: The IBM z/VM Operating System
> > >>[mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes
> > >>Sent: Thursday, November 13, 2008 10:29 AM
> > >>To: IBMVM@LISTSERV.UARK.EDU
> > >>Subject: Re: Page Space
> > >>
> > >>You didn't say how much real memory you have. Presumably
> less than
> > >>60G
> > >>:)
> > >>
> > >>You either add enough real memory or you add enough page
> > space to hold
> > >>them all (at less that 50% occupied. I don't think there
> > are miracles
> > >>available in this scenario.
> > >>
> > >>
> > >>
> > >>Marcy
> > >>
> > >>"This message may contain confidential and/or privileged
> > information.
> > >>If you are not the addressee or authorized to receive
> this for the
> > >>addressee, you must not use, copy, disclose, or take any
> > action based
> > >>on this message or any information herein. If you have
> > received this
> > >>message in error, please advise the sender immediately by
> > reply e-mail
> > >>and delete this message. Thank you for your cooperation."
> > >>
> > >>
> > >>
> > >>________________________________
> > >>
> > >>From: The IBM z/VM Operating System
> > >>[mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard
> > >>Sent: Thursday, November 13, 2008 10:20 AM
> > >>To: IBMVM@LISTSERV.UARK.EDU
> > >>Subject: [IBMVM] Page Space
> > >>
> > >>
> > >>
> > >>Yesterday, we were running a test using 17 z/TPF virtual
> > machines, 3GB
> > >>each. This was in addition to the normal load on the
> system. During
> > >>the test, which was not moving along very quickly,
> nothing was, I
> > >>noticed that our page packs were 100% allocated, up from
> the usual
> > >>10%. This stood out as a smoking gun, verified by watching the
> > >>performance improve as each of the ids in the test logged off. I
> > >>presume that this should have been expected; however,
> other matters
> > >>have kept us so busy that we did not do the math. I imagine
> > that the
> > >>one way to avoid this type of problem, we expect a peak of
> > >>approximately 150 concurrent z/TPF systems in the coming
> year, is a
> > >>massive injection of paging DASD. Is this the only answer
> > or are there
> > >>any other steps that we can take to help?
> > >>
> > >>Regards,
> > >>Richard Schuh
> > >>
> > >
> > >
> > >
> >
>
