Berry, I'd be interested in seeing a 60 minute statspack or AWR/ADDM from one of these instances at peak hour - we generally recommend direct and asynch IO, which bypasses the cache. The reports will tell you what Oracle thinks it needs based on throughput, which you can compare to what z/VM and Linux is using. Contact me off list in the first place, as attachments don't survive well.
Cheers Damian -----Original Message----- From: van Sleeuwen, Berry [mailto:berry.vansleeu...@atosorigin.com] Sent: 04 February 2010 14:32 To: LINUX-390@vm.marist.edu Subject: Re: A Question on Sizing z/VM Linux Guests We have some oracle guests that have been set to 1G. And they actually need only 300M. The rest is occupied in cache (between 650 and 710M). I'd like to decrease the machines but it is quite hard to convince the oracle group that the machines do not need the memory. Instead, they even want to increase to 2G because the books tell them to. While the documents suggest the oracle will benefit from the increased memory, in reality VM will page more and the effect is an overall decrease in performance for all guests. I would suggest to keep the guest as small as possible. Also try to limit SGA and such. Berry. -----Original Message----- From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of RPN01 Sent: donderdag 4 februari 2010 14:17 To: LINUX-390@VM.MARIST.EDU Subject: Re: A Question on Sizing z/VM Linux Guests If you're using IBM style DASD as your disk storage, you'll want to size the linux image's memory considerably smaller than what is suggested for an Intel processor. The first reason is that you have several levels of cache before the data even gets to the linux image. These layers (controller, z/VM, mdcache) will cut the time to retrieve the data, and caching it in linux as well really won't make anything any faster. The second reason is that larger images cause more paging on z/VM's part. The Intel memory suggestion is based on real memory, always available. Since this is virtual memory, your "in-memory cache" may actually be on disk anyway, causing a paging read when it is needed. You can actually slow down the response in an image by making its memory larger, because it will spend much more time paging. Finding the right size is a little more tricky. You want to start at some reasonable value (1G, 2G...), and then cut the image's memory over time until you notice it just begin to swap. Some people will allow it to do this minimal swapping, while others will increase the image size enough so that it doesn't swap at all. It just depends on which expert you choose to listen to. At this point, you'll have an image that supports the application running, but doesn't have enough memory to devote a large amount to caching its disk, which is exactly where you want to be. You may actually be surprised at how little memory this really is. -- Robert P. Nix Mayo Foundation .~. RO-OE-5-55 200 First Street SW /V\ 507-284-0844 Rochester, MN 55905 /( )\ ----- ^^-^^ "In theory, theory and practice are the same, but in practice, theory and practice are different." On 2/4/10 7:00 AM, "Carson, Brad" <cars...@labcorp.com> wrote: > We have a project that is being setup to run on RHEL under z/VM. The > sizing parameters for the guests (Oracle DB, and WebLogic) are being > sent to us based on intel platform sizing. How do some of you handle > the sizing conversion from Intel to IFL's? Are there some rules of thumb, we should know about? > > Our environment: > > IBM z10-BC (QA and Dev) and z10-EC (Prod) running z/VM 5.4 and RHEL 5.3. > > > Thanks for any insight. > > /Brad (please ignore the company inserted HIPAA disclaimer) > > ----------------------------------------- This e-mail and any > attachments may contain CONFIDENTIAL information, including PROTECTED > HEALTH INFORMATION. If you are not the intended recipient, any use or > disclosure of this information is STRICTLY PROHIBITED; you are > requested to delete this e-mail and any attachments, notify the sender > immediately, and notify the LabCorp Privacy Officer at privacyoffi...@labcorp.com or call (877) 23-HIPAA. > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, send > email to lists...@vm.marist.edu with the message: INFO LINUX-390 or > visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
