>>> On 2/11/2009 at  8:24 PM, Frank Swarbrick <[email protected]>
wrote: 
-snip-
> 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?

A lot of us have seen that happen frequently, especially if the tuning is being 
done by someone with no mainframe experience, and hence only a midrange 
mindset.  That usually goes something like this...  "Hmm.  Things are running a 
little slow.  We should add more memory to the system.  Rats, that didn't help. 
 Let's add some more processors and see what that does.  Gee, that didn't help 
either.  These mainframes are a piece of junk."  The next most common failing 
is that they will run artificial benchmarks and compare one Intel/AMD system to 
one guest running on z/VM.  What they should be doing is running real workload 
on 10 or 20 Intel/AMD systems and comparing that to 10 or 20 guests on z/VM.  
Even if they do that, they can't just look at "raw" performance, they have to 
take that and factor in the TCO of everything that goes into making those 10 or 
20 systems or guests provide that amount of work.  It's usually "hard," so most 
people don't do it.  So they do the one-to-one comparison and declare victory 
when the inevitable happens.

Yes, WebSphere startup can be rather slow, since WebSphere is a resource hog of 
the first order.  But, if you're doing things right, you shouldn't have to 
start it up very often, and if you do, there's another instance running that is 
providing service while that goes on.  Also, having a z10 makes a big 
difference as well, since the processor cycle time is considerably faster than 
a z9.

But, the fact of the matter is, some of our customers, such as Nationwide 
Insurance, run _hundreds_ of Linux guests running WAS on them, on one box, and 
they're happy with what they see.  Particularly for their mission critical 
work, including their corporate web site.  One of the big reasons for that is 
they understand z/VM and how to get the most out of it.  That means doing such 
things as making guests as small as possible, giving them as few virtual CPUs 
as possible, having Linux take advantage of as many z/VM facilities as 
possible, and so on.  Trying to get by without some real z/VM experience is 
pretty much a way to guarantee failure.

Second, they have a real z/VM and Linux performance monitor that they can use 
to understand what is really happening and make adjustments.  Other customers 
have done things such as apply application profiling tools to find areas of 
particularly poor quality application code and fix them.  In several cases, 
those applications experienced one or two orders of magnitude improvement in 
performance, with only very small changes in the application.  Anyone who's 
studied performance management will tell you that you get your biggest 
improvements just that way, since it's usually not the hardware or operating 
system that is so far out whack that things run horribly.  (They can be, but 
usually aren't in a mainframe shop.)

I could go on, but I won't.  There are workloads that aren't appropriate for 
the mainframe, even with z10 hardware.  Oracle, DB2, SAP and WAS don't usually 
fall into that group.


Mark Post

----------------------------------------------------------------------
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