As a temporary measure I issued SET QUICKDSP ON for all the Linux images
except 1. This caused some immediate paging activity that has since dropped
back down to normal levels. There are not currently any Linux systems
waiting on the eligible queue.
All SRM Values are still set to their defaults except MAXWSS.
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=5%
...... : PAGES=17956
XSTORE : 0%
q stor
STORAGE = 1536M
q xstor
HCPXST1401I Expanded storage is not available within this hardware
configuration.
q alloc page
EXTENT EXTENT TOTAL PAGES HIGH %
VOLID RDEV START END PAGES IN USE PAGE USED
------ ---- ------ ------ ------ ------ ------ ----
420RES 2271 194 277 15120 15120 15120 100%
639 688 9000 8997 9000 99%
VMPASP 2281 0 1499 270000 133939 269977 49%
VMPA01 227E 0 3338 601020 132574 285116 22%
VMPA02 227F 0 3338 601020 136540 285106 22%
VMPA03 2280 0 3338 601020 131633 285112 21%
VMPA04 2282 0 3338 601020 131783 277199 21%
VMPA05 2283 0 3338 601020 135393 284971 22%
------ ------ ----
SUMMARY 3299K 825979 25%
USABLE 3299K 825979 25%
ind
AVGPROC-035% 01
MDC READS-000003/SEC WRITES-000000/SEC HIT RATIO-100%
STORAGE-094% PAGING-0001/SEC STEAL-000%
Q0-00126(00000) DORMANT-00012
Q1-00000(00000) E1-00000(00000)
Q2-00000(00000) EXPAN-001 E2-00000(00000)
Q3-00001(00000) EXPAN-002 E3-00000(00000)
PROC 0000-035%
LIMITED-00000
-----Original Message-----
From: Malcolm Beattie [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 20, 2002 4:10 PM
To: [EMAIL PROTECTED]
Subject: Re: z/VM 4.2 Dispatching Problem running about 120 Li nux
copies
Davis, Jeff writes:
> Your indicate command shows that you have 8 users in the E list. This
> happens when you don't have enough available real storage to fit a user's
> working set in to real storage. When a user is in the E list, the system
> appears to be unavailable or down to that user. He cannot run. You can
do
> a couple of things. The best is to get more real storage. Unfortunately,
> that's not so easy. Second, you can set your SRM settings to over
allocate
> real storage. This will prevent users from going into the E list, but
will
> also drive up your paging rate. Make sure you have plenty of paging
> resource to do this.
If you post the result of
QUERY SRM
along with
QUERY STORE
QUERY XSTORE
QUERY ALLOC PAGE
then we can check whether some of your SRM settings are unnecessarily
preventing the Linux guests from being dispatched. For example, if
your DSPBUF setting was inherited from one intended for CMS guests
then it may include a "reserve" for Q1 and Q2 guests which Linux will
never be able to make use of.
As Jeff says, the next most likely reason is that storage is not being
overcommitted enough. In the absence of the timer-on-demand patch and/or
fancy footwork with mm configuration changes/patches, CP sees the entire
storage allocation of each Linux guest as one large clumped working set,
despite Linux being fairly happy (usually) to have some of it ripped
away. Because of this, in many Linux situations you can allow CP to
overcommit real storage rather heavily (while increasing paging space
to back it, of course) without the paging space actually being needed
most of the time. That's the STORBUF setting for SRM.
There's also the LDUBUF setting which causes guests to be kicked into the
eligible list if CP thinks that they are loading the paging subsystem
too much. That estimate is calculated based on how many "exposures"
the paging subsystem has: basically, how many volumes it can page to in
parallel, modulo some tweakable multipliers. The Q ALLOC PAGE I asked
for above will let you work out if that's likely to need tweaking when
you start increasing STORBUF (and assuming Linux guests turn out to need
to page significantly).
--Malcolm
--
Malcolm Beattie <[EMAIL PROTECTED]>
Linux Technical Consultant
IBM EMEA Enterprise Server Group...
...from home, speaking only for myself
