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
ÿþDit bericht is vertrouwelijk en kan 
geheime informatie bevatten enkel

bestemd voor de geadresseerde. Indien 
dit bericht niet voor u is bestemd,

verzoeken wij u dit onmiddellijk aan 
ons te melden en het bericht te

vernietigen.

Aangezien de integriteit van het 
bericht niet veilig gesteld is middels

verzending via internet, kan Atos 
Origin niet aansprakelijk worden 
gehouden

voor de inhoud daarvan.

Hoewel wij ons inspannen een virusvrij 
netwerk te hanteren, geven

wij geen enkele garantie dat dit 
bericht virusvrij is, noch aanvaarden 
wij

enige aansprakelijkheid voor de 
mogelijke aanwezigheid van een virus in 
dit

bericht.

 

Op al onze rechtsverhoudingen, 
aanbiedingen en overeenkomsten 
waaronder

Atos Origin goederen en/of diensten 
levert zijn met uitsluiting van alle

andere voorwaarden de 
Leveringsvoorwaarden van Atos Origin 
van toepassing.

Deze worden u op aanvraag direct 
kosteloos toegezonden.

 

This e-mail and the documents attached 
are confidential and intended solely

for the addressee; it may also be 
privileged. If you receive this e-mail

in error, please notify the sender 
immediately and destroy it.

As its integrity cannot be secured on 
the Internet, the Atos Origin group

liability cannot be triggered for the 
message content. Although the

sender endeavours to maintain a 
computer virus-free network, the sender

does not warrant that this transmission 
is virus-free and will not be

liable for any damages resulting from 
any virus transmitted.

 

On all offers and agreements under 
which Atos Origin supplies goods and/or

services of whatever nature, the Terms 
of Delivery from Atos Origin

exclusively apply. 

The Terms of Delivery shall be promptly 
submitted to you on your request.

 

Atos Origin Nederland B.V. / Utrecht

KvK Utrecht 30132762

Reply via email to