There are some issues with WAS right now that seriously impact Linux under
z/VM. Rob's
out of town, he can explain better. The problem is that the current JDK polls
every
10ms. this means the WAS servers stay in queue. We have been seeing the total
to virtual
storage over allocation ratios that sites can attain have been dropping, traced
it down to
servers not dropping from queue. Rob tracked it down to the WAS polling. We're
hoping for
relief next year. So be careful about the performance feecher of 6.1.
Marcy Cortes wrote:
(Hi Mark!)
I'm pretty sure all of production will be sles9x within the next 2
months - woo hoo! The promise of better performance from WAS6.1 and
sles9x saving them a few IFLs is finally getting their attention.
(see you next week).
Marcy Cortes
-----Original Message-----
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
Mark Post
Sent: Friday, September 14, 2007 9:20 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] linux performance behind load balancer
On Fri, Sep 14, 2007 at 6:48 AM, in message
<[EMAIL PROTECTED]>,
"Evans, Kevin R" <[EMAIL PROTECTED]> wrote:
Rob,
As we are just switching to Omegamon and almost up to implementation
of our first user to come into a new zLinux front end, can you give
ant further details on your comment below?
Prior to the kernels used in SLES10 and RHEL5, the way CPU consumption
was tracked by the Linux kernel didn't take into account that the system
may be running in a shared/virtualized environment. The (valid until
LPARs, z/VM, VMware, and Xen) assumption in place was that the kernel
was in complete control of the hardware, so any passage of time between
the last clock value taken, and the current one, was assigned to
whatever process was dispatched in the interval. The problem being, of
course, that the virtual machine/LPAR might not have been running at all
during that time. So, Linux could report that the CPU was 100% busy,
when in fact it was only being dispatched, for example, 3% of the time.
Of the various performance monitors that were being marketed for
mainframe Linux, only Velocity Software's product combined the Linux
data with the z/VM monitor data, and normalized the Linux values to be
correct. (Obviously this only worked in an environment where z/VM was
being used as the hypervisor.) This was a big factor in many cases of
which monitor to choose. Since the release of the "cpu accounting"
patches, and incorporation into SLES and RHEL, that's no longer the
case, unless you're still running SLES8 (Hi, Marcy!) and SLES9 (Hi,
almost everyone else!), or RHEL3 or 4. Now the decision is based on
more traditional criteria, as opposed to being right or very wrong.
If you have a userid and password to access the SHARE proceedings, you
can see Martin Schwidefsky's presentation on this at
http://www.share.org/member_center/open_document.cfm?document=proceeding
s/SHARE_in_Seattle/S9266XX172938.pdf
(I have no idea why I didn't ask Martin for a copy of that for the
linuxvm.org web site. Rats.)
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
begin:vcard
fn:Barton Robinson
n:Robinson;Barton
adr;dom:;;PO 390640;Mountain View;CA;94039-0640
email;internet:[EMAIL PROTECTED]
title:Sr. Architect
tel;work:650-964-8867
note:If you can't measure it, I'm just not interested
x-mozilla-html:FALSE
url:http://velocitysoftware.com
version:2.1
end:vcard
