Mark,

> Yes, we're paging. A lot! And the page volumes are filling up too! 
Not being a performance geek, and without any knowledge of your 
environment other except that you have Linux for System z guests, 
something sounds a little fishy.

Just guessing from other's past posts: could it be that your Linux guests 
had been given VM sizes based on what the distributed servers had?

IIRC, Linux caches a lot of files in its storage.  That's great in a 
distributed server that has lower I/O throughput (all I/O is serviced by 
the CPU on the motherboard vs. being handed off to an I/O processor on 
System z), and where distributed memory is a lot cheaper than System z 
memory.

On System z, memory is (relatively) expensive, I/O's are VERY fast (and do 
not impact the CPU much), and MDISK cache is quite good.  Giving Linux for 
System z servers lots of memory because that's what they had on 
distributed servers (presuming that the memory is mostly file caching), 
and having the Linux server also cached in minidisk cache is quite a waste 
(double caching).  IIRC, MDCACHE beats Linux cache in almost every case. 

If you have a good performance monitor for your Linux guests, try to see 
*why* they need so much memory.  If it's file cache, try reducing the vm 
size significantly (IIRC, Jim Vincent used to recommend 2G or less for 
Websphere servers).

Getting the Linux guest memory requirements reduced could improve your 
z/VM paging requirements.

Good hunting!

Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.






"Mark Wheeler" <[email protected]> 

Sent by: "The IBM z/VM Operating System" <[email protected]>
02/23/2010 11:01 AM
Please respond to
"The IBM z/VM Operating System" <[email protected]>



To
[email protected]
cc

Subject
Re: Adding different sized page volumes






Yes, we're paging. A lot! And the page volumes are filling up too! 
 
Some new 3390-27 page volumes have been added, with all 32K cyls allocated 
to PAGE, and when the 3390-9's fill up, the mod27's do go beyond the 10016 
cyl mark. I suspect (we haven't gotten this far yet) that when the mod 9's 
completely fill up, not only will block paging suffer (more), but most of 
the page-outs will be concentrated on the relatively few mod 27s. Gaackkk!
 
I'm just trying to reconcile the admonishment not to mix page volume sizes 
with what people do in the real world. Since my options don't provide for 
the *ideal* solution, my preference is to adopt one that will provide the 
maximum benefit with the smallest downside.
 
Best regards,
 
Mark
 
Date: Tue, 23 Feb 2010 08:37:06 -0800
From: [email protected]
Subject: Re: Adding different sized page volumes
To: [email protected]

My experience was that the paging will be spread evenly until the -9s 
start filling up and then the additional space in the -27s will be used. 
That was from a recent experience with a combination of -3s and -9s. I 
have since converted everything to -9s.
 
The only possible answer to the other question is, "It depends." If your 
system is not paging to DASD very much, it probably doesn't matter.  If 
you are paging to DASD, then the lower the space utilization, the more 
likely that the system can realize the benefits of block paging.
 
 
Regards, 
Richard Schuh 
 
 

From: The IBM z/VM Operating System [mailto:[email protected]] On 
Behalf Of Mark Wheeler
Sent: Tuesday, February 23, 2010 7:01 AM
To: [email protected]
Subject: Adding different sized page volumes

Greetings all,
 
We need to add more page volumes (for both space and actuators) but are 
fresh out of 3390-9's. If we throw 3390-27's into the mix, should they be 
fully allocated as PAGE, or just cyls 1-10016?
 
Will I start a religous war if I also ask about the latest recommendation 
for page volume space utilization? Max of 25%? 50%? "It Depends"?
 
Best regards,
 
Mark Wheeler
UnitedHealth Group

Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up 
now. 

Hotmail: Free, trusted and rich email service. Get it now.




The information contained in this e-mail and any accompanying documents may 
contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message, including any attachments. Any 
dissemination, distribution or other use of the contents of this message by 
anyone other than the intended recipient is strictly prohibited. All messages 
sent to and from this e-mail address may be monitored as permitted by 
applicable law and regulations to ensure compliance with our internal policies 
and to protect our business. E-mails are not secure and cannot be guaranteed to 
be error free as they can be intercepted, amended, lost or destroyed, or 
contain viruses. You are deemed to have accepted these risks if you communicate 
with us by e-mail. 

Reply via email to