Production I'm not so worried about because it has adequate capacity (no paging) and the servers run all the time anyway so don't drop from queue because of real work. They've benchmarked and measured (with Velocity tools :) the differences betweens sles9x/was6 and sles8/was5 and see significant differences. We'll let you know for sure next week with the real workload going through.
But this might explain the increased paging load on our test system, which already was bursting at the seams. Do you know what level of the JDK that started in? Marcy Cortes "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of barton Sent: Friday, September 14, 2007 1:12 PM To: [email protected] Subject: Re: [LINUX-390] linux performance behind load balancer 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: [email protected] > 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=proceedi > ng > 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 ---------------------------------------------------------------------- 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
