>>> On 2/11/2009 at 9:00 AM, in message
<[email protected]>, Mark Post
<[email protected]> wrote:
>>>> On 2/11/2009 at  8:47 AM, Erling Ringen Elvsrud <[email protected]> 
>>>> wrote: 
> -snip-
> 
> Yes, it's something that has been a point of contention for quite some time. 
>  Even with the price reduction that came with the z10, it's still more 
> expensive than a lot of people like.
> 
> The effectiveness is going to vary quite a bit with the particular workload 
> an application.  Tuning application code for any particular performance 
> problem will usually provide 80% of any relief from that problem.  But, from 
> what I've been told by people doing the work, an over-commit ratio of 1.5 is 
> fairly typical, and some people get as much as 2.0.  Just to be clear, the 
> 1.5 means that if you have 100GB on the box, you can have 150GB of virtual 
> storage in use by the guests.
> 
> Mitigating all of this is that z/VM is capable of paging much more than 
> distributed systems without a performance impact because the I/O subsystem is 
> so much better.  The other factor is that Linux for System z and z/VM can 
> cooperate in memory management to reduce the amount of "double paging" that 
> you run into on any virtualization platform.  There are other facilities in 
> z/VM that Linux has been "taught" to use, such as DisContiguous Saved 
> Segments that can reduce disk I/O as well as real memory consumption.
> 
> All in all, the big key is to not give in to developers' perceptions that 
> they need as much memory for their virtualized guests as they (think) they do 
> on discrete hardware.  We've seen any number of cases where Oracle databases 
> run quite nicely on 4-8GB of virtual memory when the developers and DBAs 
> thought they needed 32-64GB because that's what they had on Intel/AMD.  Each 
> case is different, of course, and may require some application rework to get 
> SGA sizes down to a more reasonable level without impacting performance of 
> the application.  But, with a little time and effort, it can _usually_ be 
> done.
> 
> All that said, even with the price of real storage for the z10 being as high 
> as it is, it almost always turns out cheaper to run the kind of workload you 
> say you have on Linux for System z than it is on VMware.  If you talk to your 
> IBM rep, or one of IBM's Business Partners, they have tools that can help you 
> figure out just how much that might be before you make any commitment to buy 
> a thing.  They've been refining it for a number of years now, and if they've 
> got good numbers to put into them, they can get fairly close.

I probably shouldn't open my mouth without having all of the facts, but I can't 
stop myself...  :-)

We have an IFL and have a few things running on it.  I'm only a Cobol 
applications developer so I'm not directly involved in general.  But...  We 
currently have a production DB2 running on Linux on Z.  We just bought IBM 
Federation Server.  But for Linux on Intel, not on Z.  I was told that the cost 
of memory was the driving reason we chose Intel over Z.  Apparently Federation 
Server requires a whole lot of memory.

The other reason is performance.  Apparently there have been some tests to move 
some Oracle databases from Intel to Z.  I've been told they've got performance 
on Z so that it's "only 8 or 9 times slower" than on Intel, and that's after "a 
lot of tuning".

We also have migrated some WebSphere stuff to Z and apparently it's noticably 
slower as well, especially "start up".

We have a Z9-BC (2096-U02).  The IFL runs z/VM 5.3.0 and I believe we use SLES 
10.

Comments?

I apologize for being vague.  I'm not directly involved and probably don't 
understand all of the issues.  But I am interested.

Frank


-- 

Frank Swarbrick
Senior Systems Analyst - Mainframe Applications
FirstBank Data Corporation
Lakewood, CO  USA
P: 303-235-1403
F: 303-235-2075




The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Reply via email to