On Fri, Mar 21, 2008 at 11:08 AM, O'Brien, David W. (NIH/CIT) [C] <[EMAIL PROTECTED]> wrote:
> I made the mistake of believing what I was told. One man's virtual is another man's real. We probably don't want to change CP after 40 years, but it is sometimes confusing that Q STOR returns either virtual or real depending on the CP privileges... It is easy to get confused. :story type=sad. One of my colleagues who managed DIRMAINT and thus could give himself class ABCDEFGH (sigh) opened a problem ticket about DEFINE STORAGE not working. Even after he did DEF STOR 8M and IPL CMS, Q STOR would still show him 256M (yes, long ago). :estory. So now we know that your Linux virtual machine were 768M and your z/VM is 2GB. Which means we can not have all Linux virtual machines completely resident (you also need some for z/VM itself and other users running). When your Linux virtual machines don't drop nicely from queue. > 06:01:42 LDUBUF : Q1=100% Q2=75% Q3=60% When your virtual machines do not drop from queue, they end up as Q3 and CP will only want them to take 60% of storage. > Any recommendation for LDUBUF? I just raised it to 100 100 100. Please > advise if that change was counter indicated. It may appear to address your problem, but it really does not. It does make you more likely to thrash. It will tell CP to use all storage for Q3 users when needed. It's probably not enough for the full Linux servers, but may be enough when they have just restarted and did not gobble up enough data to cache and bother z/VM. No doubt someone will suggest to raise this even way over 100. That will make your system thrash even harder (and your configuration would get into that). Don't. It does not help to tell CP to imagine it had more than it really does. The real approach is to reduce the working set of the Linux virtual machines to fit in what you have available, instead of telling CP to think that it has 2 or 3 times as much. One way to reduce the working set size is to change the virtual machines into 512M plus 256M VDISK for cache. It is almost as fast (because VDISK is data-in-memory) but discourages Linux to use it as cache. It could also be that the Linux server did not really need 768M but someone just invented the number (or used this to run the GUI installer). If the 512M + 256M does not swap, you can probably lower the 512M and see where it goes. With defaults, MDC will probably gobble up quote some of your main storage as well (check with Q MDC). Considering your system, you probably want to disable that completely. Your z/VM is rather small to current standards. If you do find you page with the workload you want to run, it might make sense to add some expanded storage (or if you have nothing left, change some main into expanded). With that, and with decent paging subsystem you might be able to challenge CP a bit and tweak the SRM settings a little. Rob -- Rob van der Heij Velocity Software GmbH http://velocitysoftware.com/
