SUMMARY: vmstat & virtual adrian

From: Stuart, Reggie (GXS, Maxim) (Reggie.Stuart@gxs.ge.com)
Date: Tue Nov 14 2000 - 13:20:09 CST


Sorry for the delay, and much thanks go out to:

Kevin Buterbaugh [Kevin.Buterbaugh@lifeway.com]
Watson, Paul [Paul.Watson@aggregate.com]
Greg Koolbeck [koolbeck@fornost.bbn.com]
Bismark Espinoza [bismark@alta.Jpl.Nasa.Gov]
Darren Dunham [ddunham@taos.com]
Hill, Alan [Alan.Hill@microcell.ca]
Richard Smith [richard.c.smith@gte.net]
john.hilger@ac.com
(If I missed you, it was an honest error). Thanks for putting up with bad
word wrap. Another thing microshaft can't do correctly.

Quickly, I had an idle server with over 100 jobs in the "w" column of vmstat
5 output. What's the deal?

First off, this column usually has nothing to do with swap space, lack
thereof or usage UNLESS you see activity in the pi po and sr columns (page
in, out, scan rate). These are jobs waiting for something, usually disk
i/o, but perhaps waiting for some rpc to complete (we've got java in solid,
liquid and gas form here). It sat at 109 for maybe two days, and slipped to
99. The next day, something happened and the value dropped to 46 in about
10 seconds. All of us lusers were at lunch, so nobody restarted cron or
anything to cause this. About five days later, we now have 19 of these
critters. I don't want them to go away until I can figure out how to get in
the kernel and have IT TELL ME the source of these jobs. There has to be a
way to do this. I know about "adb", but what key do I press? I understand
this is going beyond normal business on this listserv, but wouldn't it be
nice to have that skill? It would allow me/us to debug the heck out of some
issues, and you would NEVER have to reboot again since you could edit the
running kernel (an extremely high risk endeavor, but folks are doing it).

This issue has no solution because I am unable to determine the root cause
of the problem. Any suggestions on dumping kernel data structures (not the
whole core memory)?

Thank you all again!!

-Reggie
No reboots in 2001.

Hello Sun gods!!

I am testing out the suite of virtual Adrian tools from sunsolve to find out

why my (java) apps telent crawl. It's an E250 with a gig of RAM and two
cpu's.
Please review this strange output from vmstat 5:

 0 0 109 1018464 419096 0 0 0 0 0 0 0 2 0 0 0 322 200 81 0 0
100
 0 0 109 1018464 419096 0 0 4 0 0 0 0 2 0 0 0 316 225 80 0 0
99
 0 0 109 1018464 419072 0 0 0 0 0 0 0 2 0 0 0 324 226 82 0 1
99
 0 0 109 1018464 419072 0 0 0 0 0 0 0 2 0 0 0 321 211 80 0 0
99
 0 0 109 1018464 419072 0 0 1 0 0 0 0 3 0 0 0 329 232 91 0 2
98
 procs memory page disk faults cpu
 r b w swap free re mf pi po fr de sr s0 s6 -- -- in sy cs us sy
id
 0 0 109 1018464 419064 0 0 0 0 0 0 0 3 0 0 0 323 214 85 0 0
99
 0 0 109 1018448 419048 0 0 0 0 0 0 0 2 0 0 0 322 219 89 0 3
97
 0 0 109 1018448 419048 0 0 0 0 0 0 0 1 0 0 0 322 214 80 0 0
99
 0 0 109 1018448 419048 0 0 0 0 0 0 0 2 0 0 0 323 214 89 0 0
99
 0 0 109 1018464 419064 0 0 0 0 0 0 0 1 0 0 0 316 208 80 0 1
99
 0 0 109 1018456 419056 0 0 0 0 0 0 0 2 0 0 0 322 233 84 0 1
99
 0 0 109 1018456 419056 0 0 0 0 0 0 0 4 0 0 0 335 209 87 0 2
98
 0 0 109 1018456 419056 0 0 0 0 0 0 0 1 0 0 0 314 217 85 0 1
99
 0 0 109 1018456 419064 0 0 0 0 0 0 0 2 0 0 0 333 463 123 0 1
99
 0 0 109 1018456 419072 0 0 0 0 0 0 0 1 0 0 0 341 539 186 0 0
99
 0 0 109 1018456 418976 0 0 19 0 0 0 0 6 0 0 0 353 321 104 0 1
99
 0 0 109 1018456 418960 0 0 0 0 0 0 0 3 0 0 0 333 260 98 0 1
99

(Hopefully the word-wrap did not mash this!)
As you can see, I have a bunch of jobs sitting in swap, no cpu usage. I am
running top, and it is the top process (as usual). Am I not reading the
output right? swap is on /tmp, and there are some user files in /tmp.

Please enlighten.

-Reggie

S
U BEFORE POSTING please READ the FAQ located at
N ftp://ftp.cs.toronto.edu/pub/jdd/sun-managers/faq
. and the list POLICY statement located at
M ftp://ftp.cs.toronto.edu/pub/jdd/sun-managers/policy
A To submit questions/summaries to this list send your email message to:
N sun-managers@sunmanagers.ececs.uc.edu
A To unsubscribe from this list please send an email message to:
G majordomo@sunmanagers.ececs.uc.edu
E and in the BODY type:
R unsubscribe sun-managers
S Or
. unsubscribe sun-managers original@subscription.address
L To view an archive of this list please visit:
I http://www.latech.edu/sunman.html
S
T



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:22 CDT