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.

Hope this helps.
Jeff Davis

-----Original Message-----
From: Sivey,Lonny [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 20, 2002 8:37 AM
To: [EMAIL PROTECTED]
Subject: [LINUX-390] z/VM 4.2 Dispatching Problem running about 120
Linux copies


We are currently running about 120 Linux instances on our 1 IFL G5 with 1.5G
storage.

After I added about the 100th Linux, VM began refusing to dispatch some of
them for extremely long periods of time (hours).  If I re-IPL VM and start
all 120 Linux systems up again it runs fine for a couple days, then the
problem starts occurring again.  I Think a VM resource is being over
committed or something, so VM just decides it doesn't have the resource to
run some of them anymore so it puts them on the eligible list, but, never
dispatches them again or at least not until a resource becomes available
again which could be hours later.

INDICATE Shows:

AVGPROC-034% 01
MDC READS-000001/SEC WRITES-000000/SEC HIT RATIO-095%
STORAGE-096% PAGING-0002/SEC STEAL-000%
Q0-00002(00001)                           DORMANT-00012
Q1-00000(00000)           E1-00000(00000)
Q2-00000(00000) EXPAN-001 E2-00000(00000)
Q3-00115(00000) EXPAN-002 E3-00008(00006)

PROC 0000-034%

LIMITED-00000

Here's what RTM shows:

<USERID> %CPU %CP %EM ISEC PAG  WSS  RES   UR PGES SHARE VMSIZE TYP,CHR,STAT

VMSERVU  IDLE .00 .00  .00 .00 1178    2   .0 1178  1500    32M VUC,QDS,IDLE
VMSERVS  IDLE .00 .00  .00 .00 1169    2   .0 1169  1500    32M VUC,QDS,IDLE
OPERSYMP IDLE .00 .00  .00 .00 1193    0   .0 1193   100    32M VUX,DSC,IDLE
EREP     IDLE .00 .00  .00 .00   67    0   .0 1164   100    32M VUX,IAB,IDLE
FTPSERVE IDLE .00 .00  .00 .00   19   21   .0 1589   100    16M VUC,IAB,IDLE
CDM0007  IDLE .00 .00  .00 .00 3934 3335   .0 5373   100    32M VUS,DSC,ELIG
CDM0091  IDLE .00 .00  .00 .00 4455 3764   .0 5163   100    32M VUS,DSC,ELIG
CDM0092  IDLE .00 .00  .00 .00 7064   31   .0 7642   100    32M VUS,DSC,ELIG
CDM0099  IDLE .00 .00  .00 .00 7854   28   .0 7630   100    32M VUS,DSC,ELIG
CDM0104  IDLE .00 .00  .00 .00 7710   32   .0 7671   100    32M VUS,DSC,ELIG
CDM0105  IDLE .00 .00  .00 .00 7958 3725   .0 7634   100    32M VUS,DSC,ELIG
CDM0086  IDLE .00 .00  .00 .00 7880   26   .0 7464   100    32M VUS,DSC,ELIG
IBML01   IDLE .00 .00  .00 .00  16K  16K   .0    1   200    64M VUS,DSC,ELIG


All of the users with a status of ELIG in the list are Linux systems.  There
seems to be plenty of CPU available and paging is light.  Anyone got an idea
what might be causing VM to not dispatch these users?
_____________________________________
Lonny Sivey
System Support Division
OCLC Online Computer Library Center, Inc.
6565 Frantz Rd, Dublin, OH 43017
(614) 764-6013  FAX (614) 718-7200
mailto:[EMAIL PROTECTED]
_____________________________________


The information in this electronic mail message is sender's business
Confidential and may be legally privileged.  It is intended solely for the
addressee(s).  Access to this Internet electronic mail message by anyone
else is unauthorized.  If you are not the intended recipient, any
disclosure, copying, distribution or any action taken or omitted to be taken
in reliance on it is prohibited and may be unlawful.
The sender believes that this E-mail and any attachments were free of any
virus, worm, Trojan horse, and/or malicious code when sent. This message and
its attachments could have been infected during  transmission. By reading
the message and opening any attachments, the recipient accepts full
responsibility for taking protective and remedial action about viruses and
other defects. Galileo International is not liable for any loss or damage
arising in any way from this message or its attachments.

Reply via email to