You will run into many many such problems that are mostly
easily corrected. I would highly recommend you install a
performance monitor that will help you determine the cause
of your problem immediately.

See "www.velocitysoftware.com/esalps.html" for example.
(free trials can be arranged)
See "www.velocitysoftware.com/workshop.html" for education



>From: Gabe Torres <[EMAIL PROTECTED]>
>
>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=3D500% Q2=3D400% Q3=3D300%", 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 =3D 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







"If you can't measure it, I'm Just NOT interested!"(tm)

/************************************************************/
Barton Robinson - CBW     Internet: [EMAIL PROTECTED]
Velocity Software, Inc    Mailing Address:
 196-D Castro Street       P.O. Box 390640
 Mountain View, CA 94041   Mountain View, CA 94039-0640

VM Performance Hotline:   650-964-8867
Fax: 650-964-9012         Web Page:  WWW.VELOCITY-SOFTWARE.COM
/************************************************************/

----------------------------------------------------------------------
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

Reply via email to