I think I have a different perspective. Storage is a valueable resource. Caching takes storage. You have a choice of where to cache, your xx number of linux servers could all be big enough to cache. That is inherantly bad. Sizing of linux virtual machines is meant to reduce the cache size because linux will always use it's storage for cache, it could have data cached that has not been referenced for hours or days - not a good use of our precious storage.
Another part of this consideration, with xx servers, they are not all likely to be active at one time. So we need a way to move the cache storage from the idle servers to the active ones. If linux owns the cache, this is not possible. We control the linux server cache size by minimizing the linux servers, so that there is less room for cache. Our z/VM technology works because it shares resources. sharing storage is a big benefit. so how to share the cache? use MDC. With MDC, there is one cache that by nature will cache the most current data for the currently active servers. So what if this is one disk only used by one server. It is the active server that needs the cache, not the inactive ones. Then use a "good performance tool, esalps comes to mind" to determine if there are some disks or servers that receive no benefit and disable those disks or servers for mdc. ESALPS does report cache hits by disk, and by user. so there is LOTS of tuning feedback available to those of you with decent performance tools. There is a lot of research that has not been done on MDC in linux on vm environment. like none. The impact of record level caching vs track caching i believe improves the cache effectiveness by factor of 10 for simple reason that linux references one block on a track and MDC caches the whole track. Rarely does linux actually use multiple blocks on a single track so MDC wastes channel time, disk time and MDC storage - clearly wasting resource. But, no body uses record level caching, even though it is signficantly better for linux workloads. And there is no reason to believe that allowing disks that are only used by one server to be mdc cached is a bad idea. How else can you give a server a couple hundred MB of cache dynamically when it needs it? On the other side, i can show test cases where enabling mdc was very bad because of the track cache. didn't matter if they were shared or not. Bottom line, there is no ROT (rule of thumb) that is valid here other than try it, measure it, validate it and do it again. >After thinking about it a little more since my reply on Friday... > >If you have a good performance monitor that can measure the MDC hit rate >on your Linux packs (note I said hit rate, not hit ratio), if MDC has a >high hit rate, then MDC is working well for that pack. If it has a low >hit rate, perhaps it makes sense to turn it off. > >Why hit rate instead of hit ratio? You can have a high hit ratio, but >if you are only doing 1 I/O per second, it doesn't matter. > >But if the MDC hit rate eliminates 50 I/Os per second (for example), >then MDC is working well. > >Of course if the sum of all other MDC dasd is swamping the MDC, then MDC >will have, in total, a low hit ratio. If the dasd subsystem can handle >the I/O, then turn off MDC for your low priority workloads and/or >increase the storage for MDC. If your dasd subsystem isn't able to >handle the I/O workload, either increase caching (to reduce the real >I/Os), add channels/controllers/convert to ficon to increase I/O >capacity or change your applications to reduce the I/O needs. > >Last Friday, what I was trying to say, but as I reread my post, I didn't >directly say it, was: > >What is your critical resource? > >Currently, mine is main memory and my perception is more from a memory >viewpoint. Funny, I went from 1GB to 8GB and I think that is our >critical resource. Right now, I think memory is the limiting factor in >determining the amount of work we can do. (I use to run Oracle under VM >on a 4381 92E, with 16 MBs that also supported two VSE machines which >supported 400 users. 16MB! Now Oracle 10g need 512MB to install. I >hope to get running test systems in about a quarter of that.) > >Tom Duerbusch >THD Consulting > >Phil Smith III wrote: >> James Melin <[EMAIL PROTECTED]> wrote: >> >>>My VM guy here is saying that he read some place that having mini-disk >>>cache turned on for mini-disk volumes used by linux for system disk is a >>>good thing. >> >> >>>My position has always been that Linux is caching what VM is caching and >>>it's a double fault. Since I'm not the VM guru (and neither is he really, >>>been doing VM here for just over a year) I don't have any traction in >>>getting this changed. >> >> >> As others have noted, "It depends" (and some of what I'm about to write also > maps to what you and others have said; I'm not going to keep saying "as x > said", for brevity). At the one end of the spectrum you have swap, which > probably never (for varying values of "never") makes sense to cache. At the > other end, you might have a heavily used R/O minidisk, which makes a fair > amount of sense to cache *if the performance boost that this suggests is > important*. >> >> Yes, stuff will get double-cached (triple-cached, if you count the controller > to some extent; you can't stop that. But you can control it a bit, by > carefully tuning virtual machine sizes to minimize the amount of storage > available for file cache, and then use minidisk cache. Assuming you have any > handle on load on the machines, of course. >> >> VM minidisk cache is pretty smart; I'd be surprised if turning it on was > generally a *bad* thing. Certainly turning it on for any frequently read data > seems like it should be a good thing. We do recommend that the R/O minidisks > that are part of the shared filesystem used by our product be cached, but > that's a special case. >> >> And, of course, the bottom line is that VM can generate monitor data to let > you really see whether it's doing any good. And Barton (or ASG) will be happy > to sell you his product to analyze that data. >> >> ...phsiii >> "If you can't measure it, I'm Just NOT interested!"(tm) /************************************************************/ Barton Robinson - CBW Internet: [EMAIL PROTECTED] Velocity Software, Inc Mailing Address: 196-D Castro Street P.O. Box 390640 Mountain View, CA 94041 Mountain View, CA 94039-0640 VM Performance Hotline: 650-964-8867 Fax: 650-964-9012 Web Page: WWW.VELOCITY-SOFTWARE.COM /************************************************************/ ---------------------------------------------------------------------- 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
