We run 24 hours/day, there is no convenient time. And the test is just a precursor to daily demand. By the end of January, every TPF guest will be of the 3-8GB variety, probably a few as big as 32G. The latter will be scheduled for weekends when demand is lower.
Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L > Sent: Thursday, November 13, 2008 11:26 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Page Space > > Or you schedule your test at a time when you can take a > sufficient number of your normal guests down. > > Dennis > > Bitterly clinging to my guns. > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Marcy Cortes > Sent: Thursday, November 13, 2008 10:29 > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: [IBMVM] 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 >
