Larry writes:
> We have a site which does not have glancexl.  Is there a way of finding
> the process number of the memory manager.  So that by looking at two
> showproc listings one can estimate the load of the memory manager on a
> system?

As Scott M wrote, no.

However, on the chance that you aren't really interested in the memory
manager so much as in overall performance...

If you're concerned that you don't have enough memory, then you can
do a relatively simple test.  When your throughput isn't as good
as you want (i.e., during a period when you think there might
not be enough memory), check the CPU "speedometer".  On the hardware
console, press control-B, and then observe the hex number in the lower
left of the status line.  It should alternate between FFFF and FxFF.
That "x", multiplied by 10, is the percentage busy of the CPU.  Thus,
F8FF is 80% CPU busy.  FAFF is 100% CPU busy.  F0FF is idle.
(Enter: CO <return> to turn off the display)

Ok...what's the value?  My rule of thumb is that if the value is about
70% or so, you can benefit from a faster CPU.  If it's below 70%, then
you *might* benefit from more memory.  Why the doubt?  Well, we started
with the proposition that the machine was busy ... so why isn't it fully
utilizing the CPU?  Because processes are waiting for something(s).

There are three basic things processes wait for:

   time (e.g., PAUSE intrinsic)

   disk I/O  (e.g., random disk reads, or memory manager handling a page fault)

   locks (e.g., DBLOCK, FLOCK, or internal locks done by the
          operating system and/or subsystems and/or applications).

From the speedometer, we can't tell what kind of waits are being done.

Of the above three classes, only some of the disk I/Os can be alleviated by
adding extra memory.  Paradoxically, in some cases, extra memory can increase the costs
of some locking operations (e.g., FLOCK).

Bottom line: if you're asking because you think more memory might help...
do some tests, borrow the memory, do some tests.  If it helped, buy the memory.

--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html