>>> 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? We had seen some issues with the 10.2.0.3 level and performance on s390x. The default CBO - Cost based Optimizer, simply did not produce an efficient execution plan. When we used the RBO - Rule based optimizer the CP Consumption went from near capacity to LT 10%. Response time went from 20 seconds to around 2. These were very expensive queries as well. Bottom line was the application was poorly written to begin with and with ZERO application changes we were able to increase performance and decrease CP consuption by ORCL. Gerard -----Original Message----- From: Linux on 390 Port [mailto:[email protected]] On Behalf Of Mark Post Sent: Thursday, February 12, 2009 12:48 AM To: [email protected] Subject: Re: Advice on zLinux for a systems-administrator from the x86 world >>> 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 ---------------------------------------------------------------------- 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
