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
Re: Page Space
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
Re: Page Space
Sorry - I missed the in addition to normal load part. That must have been taking up a good chunk of it. 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. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 10:36 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Page Space 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
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
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
Re: Page Space
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
Re: Page Space
Sounds like you'll be needing a boatload of paging DASD. Don't forget you only get 256 cp owned slots. So maybe you want to use mod 9. 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. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 11:38 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Page Space 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
Re: Page Space
The 256 slot limit will force me to get larger disks. We have been using mod3s. I guess I will ask for enough mod9s to replace the existing and add additional space. 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 11:41 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Page Space Sounds like you'll be needing a boatload of paging DASD. Don't forget you only get 256 cp owned slots. So maybe you want to use mod 9. 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. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 11:38 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Page Space 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
Re: Page Space
This was not in an LPAR that runs Linux. It if TPF that is growing out of control. We didn't hit any server, just the everyday users of our non-Linux VM system. Lucky? Yes and no. We had already increased page space to account for what we were told would be the average size of a z/TPF machine. We were used to running at less than 10% allocated. And we had also increased spool to allow for z/TPF dumps. Together, they kept us out of the really deep stuff. 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
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
Re: Page Space
I have to find the stuff, but at the z Expo we were told that mixing DASD types in a page farm is BD! I don't remember right off hand why. Maybe someone else can chime in while I research. On Thu, Nov 13, 2008 at 3:28 PM, Schuh, Richard [EMAIL PROTECTED] wrote: 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 -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317
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
Re: Page Space
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
Re: Page Space
Nah, mixing device types won't hurt much. as they fill, they start performing worse, and vm balances the load to ensure optiomal performance. read about mload. Mark Pace wrote: I have to find the stuff, but at the z Expo we were told that mixing DASD types in a page farm is BD! I don't remember right off hand why. Maybe someone else can chime in while I research. On Thu, Nov 13, 2008 at 3:28 PM, Schuh, Richard [EMAIL PROTECTED] wrote: 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
Re: Page Space
Marty did an excellent job of summarizing the effects of mixing sizes. Unpleasant in extreme cases yet infintely better than zero performance. That's what Brian Wade described in the case studies at the zExpo.
Re: Page Space
On Thursday, 11/13/2008 at 01:20 EST, Schuh, Richard [EMAIL PROTECTED] wrote: 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? Make sure your dasd subsystem is up to the task, using your fave perf monitor to keep an eye on I/O response times. Alan Altmark z/VM Development IBM Endicott
