mlewis@unocss.UUCP (Marcus S. Lewis) (10/20/89)
I have just bid goodbye to Data General computers, after a 5-year career as
local guru and performance expert. Hey, DG Review loves me! But my future
lies more with programming than with managing, no mater how much I like it.
It doesn't pay worth a peanut. My new job is as an Ada programmer on a VAX.
BUT, has anyone else used Brian Johnson's PERFMON? Or HAZEL? I have been
using both products for a long while (PERFMON for 2 years, HAZEL since rev
0.40) and really like them. The biggest advantage to PERFMON over DG's
Performance Monitor is simplicity. On one screen, you can get almost all
the data DG's product provides in about 20 programs. His report generator
even uses "graphics". This is not a commercial, since I have met Brian once,
and talked to him on the phone last week for about ten minutes. I just wish
more people would write commercial-grade software like that, and support it
as well has he does, with his prices.
NOW: I said I talked to Brian last week, and this was after a few hours with
Atlanta. He solved the problem in ten minutes. PERFMON gives a display of
memory usage, broken down by SYSTEM (resident and cache), USER (total and
shared) and the LRU and FREE chains. I had a new modem user break off rather
than log out, which generated an immense (15+ MB) break file. When that was
finished, I had "total user memory" at 9 Mb (late in the day) and the shared
portion of this was 14Mb. I also had 86 of 99 processes swapped with 14Mb
between the LRU and FREE chains, plus 70% idle CPU. This sure LOOKED like
a problem, since my system averaged (over the last two years) 2-3 swapped
pids over the whole day.
Brian said that (a) I should disable breakfiles. No sweat, I had to call our
Mumps vendor, but they gave me the patch on the phone. This eliminated the
problem entirely. The alternative was to patch the Agent, always a fun thing
to do, to keep it from sucking up all the available pages to generate
breakfiles. More importantly, he said (b) that the "shared" memory number was
the sum of allocated user memory and shared memory pages left on the LRU
chain. This is a limit inside AOS/VS, and what it reports when asked about
shared memory. Once the LRU pages were flushed, the disparity cleared up, and
the memory questions were answered.
Anybody ever play with this kind of stuff? This is one of the reasons I have
been so reluctant to embrace Unix. Never having been allowed to play with
performance on a Unix box, I have no idea what kinds of tools you can use
to fix a busted system, or tune a sloppy one. Not near enough traffic in
this group.
Marc
--
---------------------------------------------------------------------------
Na khuya mne ehto gavno? | Internet: cs057@zeus.unl.edu
preferred machine->| UUCP: uunet!btni!unocss!mlewis
---------------------------------------------------------------------------