Hi Daniel, We had this very same problem last week. It seemed to come out of nowhere. We are still in 'discovery' mode with z/VM and Linux on our z900, so I didn't think it was a cpu problem (low usage), but I suspected a paging problem so I added another paging volume,...then another,..but the problem persisted. The page space utilization percentage just kept growing.
The other Listserv responses to your problem are right on. IBM suggested we change the SRM parms, particularly the STORBUF parm. Ours SRM parms were set to the default. We bumped the parm up to "STORBUF: Q1=500% Q2=400% Q3=300%", and our lock-out problem went away. Paging is cruising at 23%, instead of 80%. We are looking at the other tuning parms in SRM, as IBM suggested. Gabe Torres - Systems Programmer State of Nevada Dept of Information Technology - Computing Div. This communication, including any attachments, may contain confidential information and is intended only for the individual or entity to whom it is addressed. Any review, dissemination or copying of this communication by anyone other than the intended recipient is strictly prohibited. If you are not the intended recipient, please contact the sender by reply e-Mail and delete all copies -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Daniel Jarboe Sent: Monday, November 22, 2004 4:53 AM To: [EMAIL PROTECTED] Subject: VM dispatching A few weeks ago we had what over time grew into a big problem dispatching guests. Guests would stop being dispatched sometimes for 10 minutes at a time, for no reason that we could identify. Usually shutting some guests down would get everyone dispatching again, but it was a mess. We applied some VM PTF's (like UM30888) and things got much better, but there are still times early in the morning where our performance guy's accounting records show the guests getting zero cycles in a minute interval or two. For example, last Wednesday a few guests got zero cycles (averaged over minute intervals) at 00:23:00-00:25:59, and this morning it was 4 guests from 00:21:00-00:23:59 (specifically linintra 00:21:00-00:23:59, linsmtp 00:21:00-00:22:59, linwsm 00:21:00-00:22:59, linps1 00:22:00-00:23:59). An IND Q shows that we now have non quick dispatch guests running in queues other than Q3, which is different than from before the PTFs (we are on z/VM 4.3 Guestlan). IND Q TCPIPII Q0 PS 00000419/00000084 AI00032 Q1 R00 00001165/00001144 TCPIP Q0 R 00001054/00000367 LININTRA Q2 PS 00012923/00012885 LINPROXY Q0 PS 00015499/00015461 LINSMTP Q1 PS 00012242/00012183 LINFS1 Q3 PS 00045610/00053128 LINPS2 Q1 PS 00004611/00004544 LINPOP Q3 PS 00006052/00005455 LINFS3 Q3 PS 00024126/00038166 LINFS2 Q3 PS 00054785/00065536 LINUX1 Q3 PS 00006535/00007603 Occasionally we will see these messages in linux syslog: Nov 17 00:25:14 linpop kernel: addrconf_verify(): too slow; jiffies - now = 63 We run the guest's storage pretty tight on the linux side; our largest three images are 256MB (the samba file servers), with VDISK allocated as needed (our most active one right now has another 256MB split over 4 VDISKs). Our smallest guest is 32MB. Are there any VM commands we can use to get a better idea why VM might stop dispatching some of the guests temporarily, or any other ideas/suggestions anyone can offer? Thanks, ~ Daniel ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
