it can be a memory hog but it drops from queue when true work is done, and doesn't have this neverendingqueuefourpolling problem. Note: queue 4 doesn't really exist in zvm i just coined the term to connote my utter frustration with false work never endus. I support clients with many small Oracles, others with few huge Oracles, and both work really well. Unlike WAS environments. David
________________________________ From: The IBM z/VM Operating System on behalf of Mary Anne Matyaz Sent: Wed 1/28/2009 12:04 PM To: [email protected] Subject: Re: [IBMVM] Linux Guest 'swapping' 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. >
