Issue CP IND USER linuxXyz Then we can see how big your Linux guest is. The Q V STOR is followed by a Ready message, which tells us it is executed under CMS, hence probably not in the Linux guest, but e.g. in MAINT, and your command would reveal how big MAINT is defined.
2008/3/21, O'Brien, David W. (NIH/CIT) [C] <[EMAIL PROTECTED]>: > I made the mistake of believing what I was told. > > cp q storage > 05:57:21 STORAGE = 2G > Ready; T=0.01/0.01 05:57:21 > cp q virtual storage > 05:57:35 STORAGE = 128M > Ready; T=0.01/0.01 05:57:35 > > cp q srm > 06:01:42 IABIAS : INTENSITY=90%; DURATION=2 > 06:01:42 LDUBUF : Q1=100% Q2=75% Q3=60% > 06:01:42 STORBUF: Q1=300% Q2=300% Q3=300% > 06:01:42 DSPBUF : Q1=32767 Q2=32767 Q3=32767 > 06:01:42 DISPATCHING MINOR TIMESLICE = 5 MS > 06:01:42 MAXWSS : LIMIT=9999% > 06:01:42 ...... : PAGES=999999 > 06:01:42 XSTORE : 0% > > Any recommendation for LDUBUF? I just raised it to 100 100 100. Please > advise if that change was counter indicated. > > > Thank you, > Dave O'Brien > National Institutes of Health > > > > ________________________________ > > From: Gentry, Stephen [Sent: Thu 3/20/2008 2:51 PM > > Subject: Re: Performance problem Linux under Zvm > > > > > What command did you use to determine that you had 768m central storage? > QUERY STOREAGE? > QUERY VIRTUAL STORAGE? > Steve G. > > -----Original Message----- > > Subject: Re: Performance problem Linux under Zvm > > Thanks John > > cp q srm > IABIAS : INTENSITY=90%; DURATION=2 > LDUBUF : Q1=100% Q2=75% Q3=60% > STORBUF: Q1=300% Q2=200% Q3=200% > DSPBUF : Q1=32767 Q2=32767 Q3=32767 > DISPATCHING MINOR TIMESLICE = 5 MS > MAXWSS : LIMIT=9999% > ...... : PAGES=999999 > XSTORE : 0% > > Just got the following from one of the other techs (non-VM) > > > We were able to diagnose the problem and make the necessary correction. > > The problem was z/VM has a total 768m of central available. The Linux > guests (3 total) each had 768m of central allocated, therefore > contention. > > The Linux guests are over allocated and are storage constrained with > 768m of central. > > Understanding the Linux guests would be in contention with each other > for this storage VM time sliced what it could for each > > guest, therefore the symptoms we experienced. > > > > My question to this group - Does a Linux quest really require 768MB of > Central? > > Regards, > > Dave O'Brien > > > ________________________________ > > From: Romanowski, John (OFT) > > Subject: Re: Performance problem Linux under Zvm > > > > If CP INDICATE QUEUES shows an En (like E3) > in the 2nd column for one or more userids > try CP QUERY SRM (write down response for reviewing ) > and do this quick fix > CP SET SRM STORBUF 300% 300% 300% > > > -------------------------------------------------------- > This e-mail, including any attachments, may be confidential, privileged > or otherwise legally protected. It is intended only for the addressee. > If you received this e-mail in error or from someone who was not > authorized to send it to you, do not disseminate, copy or otherwise use > this e-mail or its attachments. Please notify the sender immediately by > reply e-mail and delete the e-mail from your system. > > > -----Original Message----- > > > Subject: Performance problem Linux under Zvm > > Our shop is new to Zvm and Linux. We have a very small number of Linux > users who are reporting significant response time problems. It almost > seems as if each stops running for a period of time and is then > re-dispatched. > > Is there a VM parameter that we might have taken the default on that > needs tweaking? > > Any help or advice appreciated as this is a proof of concept endeavour > and we would like not to turn off prospective users from the start. > > Thank you, > Dave O'Brien > National Institutes of Health > -- Kris Buelens, IBM Belgium, VM customer support
