HA HA ha ha!!! Seriously? I don't have any experience with WAS, but Oracle is a definite memory lover. MA
On Wed, Jan 28, 2009 at 11:08 AM, David Kreuter <[email protected]>wrote: > .... with the effect of diminishing the value of virtualizing on this > platform. Over commit ratios of 1.5 just aren't sufficient enough to have > an attractive TCO in the case of WAS and other IBM applications. The darn > WAS machines never queue drop. > > Oracle a non-IBM product does not have this issue, and as a result over > commits can be much higher. > > David Kreuter > > ------------------------------ > *From:* The IBM z/VM Operating System on behalf of Barton Robinson > *Sent:* Wed 1/28/2009 10:36 AM > *To:* [email protected] > *Subject:* Re: [IBMVM] Linux Guest 'swapping' > > The last time I looked at the cost of swap to vdisk, at 1,000 per > second, used 10% of an 890 processor. It's very hard to constrain a > system to swap this much, this was in the lab pushing limits not > normally pushed. With z10 IFL significantly faster, swapping to vdisk > would not be a significant cost. > > The largest performance problem facing us today is storage, as IBM > Software Group has decided to put polling back into their applications > (remember the hertz timer in Linux we eliminated in 2003? - it's back > courtesy of IBM applications). With polling, the over commit ratio you > can attain is now about 1.5 - so reducing Linux storage sizes and > causing some swap means more Linux servers per installed storage. > > Robert J Brenneman wrote: > > Just a guess till the experts chime in: > > > > Linux disk I/O activity requires more CPU time than traditional Z > > Operating systems - so when one guest starts driving 5000 I/O ops per > > second to the swap device ( FBA mode vdisk in my case ) that in itself > > consumes a big chunk of CPU. Then there's the additional time spent in > > the linux kernel itself deciding what needs to go out to swap and what > > needs to come back in. > > > > let me re-emphasize this is a guess - I'd like to know the answer to this > too. > > > >
