3 guests at 512MB. With Linux all pages will be touched and become part of the working set. z/VM calculates total working set requirements = 3 * 512MB and compares it against what's available c.1488 * 0.95 (95% for Q3 STORBUF). It then determines that not all Linux guests can be dispatched and will therefore put one of them in the eligible queue.
What you want to do is either or both of these: (1) Reduce guest size to what's actually needed by the app. (2) Change STORBUF value to something that allows you to overcommit storage for Q3 guests (what that value is varies from site to site). By allowing z/VM to overcommit it will then let the machines be dispatched and the system will page when needed. The default SRM settings are an artifact of the days when CMS user type work was the main thing the system did. These were the quick running transaction types where there'd be long pauses between activity (as the user hit the enter key when editing). Your performance tool will help you adjust these values. If you have ESAMON etc. then the ESATUNE report should help you here. Neale -----Original Message----- I am reviewing all the links in case something has changed or I had missed something in the past. My SRM settings are: q srm IABIAS : INTENSITY=90%; DURATION=2 LDUBUF : Q1=100% Q2=75% Q3=60% STORBUF: Q1=125% Q2=105% Q3=95% DSPBUF : Q1=32767 Q2=32767 Q3=32767 DISPATCHING MINOR TIMESLICE = 5 MS MAXWSS : LIMIT=9999% ...... : PAGES=999999 XSTORE : 0% ---------------------------------------------------------------------- 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
