Re: Expanded storage question
We have a different situation from you Martha in that we can't add more central storage. Our current experience is that with a heavily over-committed lpar large amounts of expanded storage allows for reasonab le performance with high paging rates. I include output from the vir2real exec to see the config we are running, this is dev/test NOT PROD, and we are increasing xstore to 32Gb this week end. Storage information for VM system VLB2 Any userid using NSSes CMS GCS are considered CMS users. Total Virtual storage (only ids not running CMS): 732340 MB ( 715.2 GB) Total Virtual storage (only ids running CMS):1200 MB (1.2 GB) Total Virtual storage (all logged on userids): 733540 MB ( 716.3 GB) Usable real storage (pageable) for this system:259884 MB ( 253.8 GB) Total LPAR Real storage: 262144 MB ( 256.0 GB) Expanded storage usable for paging: 24544 MB ( 24.0 GB) Total Virtual disk (VDISK) space defined: 17285 MB ( 16.9 GB) Average Virtual disk size: 98 MB Virtual to (usable) Real storage ratio: 2.8 : 1 Virtual + VDISK to Real storage ratio: 2.9 : 1 Virtual to Real ratio (non CMS work only): 2.8 : 1 Paging: 18 volumes defined, total space is: 413696 MB ( 404.0 GB) Total Paging space in use (60% utilization): 248864 MB ( 243.0 GB) Ready;
Re: Expanded storage question
Phil, you might want to add some paging vols. We've noticed that things go down hill fast when paging space is 50% (in our dev/test env with mostly WAS). Marcy -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Philip Tully Sent: Friday, December 17, 2010 5:33 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Expanded storage question We have a different situation from you Martha in that we can't add more central storage. Our current experience is that with a heavily over-committed lpar large amounts of expanded storage allows for reasonab= le performance with high paging rates. I include output from the vir2real exec to see the config we are running,= this is dev/test NOT PROD, and we are increasing xstore to 32Gb this week= end. = = Storage information for VM system VLB2= = Any userid using NSSes CMS GCS are considered CMS users. = = = = Total Virtual storage (only ids not running CMS): 732340 MB ( 715.2 GB)= Total Virtual storage (only ids running CMS):1200 MB (1.2 GB)= Total Virtual storage (all logged on userids): 733540 MB ( 716.3 GB)= Usable real storage (pageable) for this system:259884 MB ( 253.8 GB)= Total LPAR Real storage: 262144 MB ( 256.0 GB)= Expanded storage usable for paging: 24544 MB ( 24.0 GB)= = = = Total Virtual disk (VDISK) space defined: 17285 MB ( 16.9 GB)= Average Virtual disk size: 98 MB = = = = Virtual to (usable) Real storage ratio: 2.8 : 1= Virtual + VDISK to Real storage ratio: 2.9 : 1= Virtual to Real ratio (non CMS work only): 2.8 : 1= = = = Paging: 18 volumes defined, total space is: 413696 MB ( 404.0 GB)= Total Paging space in use (60% utilization): 248864 MB ( 243.0 GB)= Ready; = = =
Re: Expanded storage question
Philip, What's your paging rate with this configuration? 18 paging volumes seems low for this amount of storage. Dennis Christmas dawned clear and cold; lovely weather for killing Germans, although the thought seemed somewhat at variance with the spirit of the day. -- War as I knew it, by Gen. George S. Patton, Jr. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Philip Tully Sent: Friday, December 17, 2010 05:33 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Expanded storage question We have a different situation from you Martha in that we can't add more central storage. Our current experience is that with a heavily over-committed lpar large amounts of expanded storage allows for reasonab le performance with high paging rates. I include output from the vir2real exec to see the config we are running, this is dev/test NOT PROD, and we are increasing xstore to 32Gb this week end. Storage information for VM system VLB2 Any userid using NSSes CMS GCS are considered CMS users. Total Virtual storage (only ids not running CMS): 732340 MB ( 715.2 GB) Total Virtual storage (only ids running CMS):1200 MB (1.2 GB) Total Virtual storage (all logged on userids): 733540 MB ( 716.3 GB) Usable real storage (pageable) for this system:259884 MB ( 253.8 GB) Total LPAR Real storage: 262144 MB ( 256.0 GB) Expanded storage usable for paging: 24544 MB ( 24.0 GB) Total Virtual disk (VDISK) space defined: 17285 MB ( 16.9 GB) Average Virtual disk size: 98 MB Virtual to (usable) Real storage ratio: 2.8 : 1 Virtual + VDISK to Real storage ratio: 2.9 : 1 Virtual to Real ratio (non CMS work only): 2.8 : 1 Paging: 18 volumes defined, total space is: 413696 MB ( 404.0 GB) Total Paging space in use (60% utilization): 248864 MB ( 243.0 GB) Ready; -- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to Sender are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.
Re: Expanded storage question
Thanks, I do concur the 50% recommendation is a solid one. As we have experienced that pain point more than once, this system had an expected spike last night when we started an additional 36 4G linux guest s which are being brought down this morning at which point we will re asses s. This is also the first system we started using mod27's for paging, so we are keeping a strained eye on it.
Re: Expanded storage question
Current paging is a mere 1000 pps, we just moved from 40 mod9's to 18 mod 27's This is an ugly system with 300+ linux guests defined, 200+ logged on an d our guests running multiple was JVMs run anywhere from 1Gb-9.5Gb Just keep chanting it ain't prod , it ain't prod
Re: Expanded storage question
To be explicit, I would allocate 5GB of your 35G z/VM LPAR to expanded storage, and leave 30GB as central. On 12/16/2010 12:50 PM, Martha McConaghy wrote: I know that this question has come up numerous times in the past, but I'm don't recall ever seeing a consensus on it. I know that z/VM needs expanded storage. However, deciding how much is the trick. We will be moving to a z10 early in the new year. I'm trying to decide how to divide the storage. If an LPAR is going to be running a lot of Linux guests (some of them quite large), is it better to put as much storage into main as possible with a small expandedor cut back on the amount of main and put it towards expanded? I've done the former in the past. However, we now have a lot more Linux servers than ever before, some of which are running pretty heavy apps, like Oracle. The current LPAR does do a lot of paging to expanded and disk. While there will be more storage on the z10, it isn't a lot amount more. So, for example, if I have 35G to use for 1 LPAR, would it be better to define 30G main and 5G expanded or 25G main and 10G expanded? Martha -- Dave Jones V/Soft Software www.vsoft-software.com Houston, TX 281.578.7544
Re: Expanded storage question
Martha, we found it is better to go with some xstor but not a lot we found it is better to page to xstor than dasd we tried it with a lot of XSTOR and a little XSTOR so 30 central and 5 expanded sounds good munson 201-418-7588 From: Martha McConaghy u...@vm.marist.edu To: IBMVM@LISTSERV.UARK.EDU Date: 12/16/2010 01:56 PM Subject:Expanded storage question Sent by:The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU I know that this question has come up numerous times in the past, but I'm don't recall ever seeing a consensus on it. I know that z/VM needs expanded storage. However, deciding how much is the trick. We will be moving to a z10 early in the new year. I'm trying to decide how to divide the storage. If an LPAR is going to be running a lot of Linux guests (some of them quite large), is it better to put as much storage into main as possible with a small expandedor cut back on the amount of main and put it towards expanded? I've done the former in the past. However, we now have a lot more Linux servers than ever before, some of which are running pretty heavy apps, like Oracle. The current LPAR does do a lot of paging to expanded and disk. While there will be more storage on the z10, it isn't a lot amount more. So, for example, if I have 35G to use for 1 LPAR, would it be better to define 30G main and 5G expanded or 25G main and 10G expanded? Martha *** IMPORTANT NOTE*-- The opinions expressed in this message and/or any attachments are those of the author and not necessarily those of Brown Brothers Harriman Co., its subsidiaries and affiliates (BBH). There is no guarantee that this message is either private or confidential, and it may have been altered by unauthorized sources without your or our knowledge. Nothing in the message is capable or intended to create any legally binding obligations on either party and it is not intended to provide legal advice. BBH accepts no responsibility for loss or damage from its use, including damage from virus.
