Yep, rule of thumb as well as 98% of the time, vdisk for swap is the way to go.
But there still is use for swap on real disk. One is to throttle the image,
the other is to keep the max resident size down sufficiently enough to keep
from impacting production systems by overloading the paging system.
A lot can be done with the paging system, especially if you have the money.
But for those of us that occasionally hit a paging cliff.... It would be
better if there was a command to limit the amount of resident memory a guest
could have. Something like your resident memory plus dataspace resident memory
couldn't exceed 512 MB. When I think about what it would take to modify the
paging subsystem, to prefer some users memory for pageouts, my brain starts
hurting.
Until then, swap on real disk can help reduce the problem.
I got a request in from a Network guy that wants a Linux image to play around
with. Initially some sort of network performance monitor. I won't have time
to sit with him to keep the normal, "I got a box that I'm the only user on, and
it doesn't matter what I do" mentality, so I do need to keep his resident size
down. So, a couple vdisk swap disks, and a full 3390-3 real swap disk.
If things go well, and his application is ready for prime time with his memory
requirement really known, then swap disks will be redefined, without the real
disk.
There are always exceptions to the rule.
But then, if I had the funds for a real performance monitor, I might be able to
see a different solution. Right now, my alerts come in the form of the phone
ringing.
Of course, if I had more funds to buy more memory, I could create another LPAR
and have these "weird" images in their own Linux farm. But that would then
require me to dedicate real resources to a set of images that, on any given
day, may never be used. Dedicate real memory vs dedicate real dasd. I have
more dasd, for now.
Tom Duerbusch
THD Consulting
>>> Doug Shupe <dsh...@bellsouth.net> 4/29/2009 8:58 PM >>>
Scott you hit this one on the head!
Penguins multiply rapidly, real memory tends to stay constant ($$$). Sure VM is
Great at paging but, like you say, impacting all the Penguins? YMMV. Alerts are
a must either way. When memory is at a premium, one v-disk and the rest real
disk is the way to go. DASD is not 'that' slow anymore.
Doug
----- Original Message -----
From: Scott Rohling
To: IBMVM@LISTSERV.UARK.EDU
Sent: Wednesday, April 29, 2009 18:13
Subject: Re: SWAPGEN
Maybe -- but having a real disk (and setting an alert for that) helps
isolate the issue to a single guest rather than affecting critical shared
resources (in this case memory/paging) when a guest starts swapping more than
normal or than it 'should'.
I like the idea of having a 'failover' swap area on real disk -- whether you
have a single VDISK or 2 prioritized ahead of it. I guess whether it's waste
of resource depends on your POV.. But your point is taken..
Scott
On Wed, Apr 29, 2009 at 4:42 PM, Barton Robinson
<bar...@vm1.velocity-software.com> wrote:
giving real disks to swap is a real waste of resource. It is much better
to take the "extra disk resource" that you allocate but never want to use, and
assign it to z/VM paging to enhance your paging subsystem. Then define two
vdisks for swap, prioritize them, and set an alert when the 2nd disk is being
used.
Martin, Terry R. (LOCKHEED MARTIN Performance Engineering/CTR) (CTR) wrote:
Hi
I am using SWAPGEN to define by z/Linux VDISKS I also want to define a
real disk for swap. My question is can I use SWAPGEN to define a swap on real
DASD? If you have an example of the control card syntax to accomplish this that
would be great?
//Thank You,//
//Terry Martin//
//Lockheed Martin - Information Technology//
//z/OS & z/VM Systems - Performance and Tuning//
//Cell - 443 632-4191//
//Work - 410 786-0386//
//terry.ma...@cms.hhs.gov <mailto:terry.ma...@cms.hhs.gov>//
