We have a holiday freeze to contend with, so I have no choice except to use what is already at hand or can be obtained in the next 3 days without spending any money. The only paging we see is when we have a bunch of these miscreants on the system, so it might be better for me to take the chance and mix the sizes. I think I would rather do that than run out of real estate. I will not be able to replace the dasd until some time after mid January.
Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Marty Zimelis > Sent: Thursday, November 13, 2008 12:37 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Page Space > > 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 > > > >> > > > > > > > > > > > > > > > > > >
