memhog/u386mon/ps Why the differences?
Ken Wolff
Skunk98), u386mon 2.74 and ps and each gives me a different memory size.
memhog shows 1228
u386mon shows 14868
ps -lp shows 12620
Can anyone give me some light here? Which one should be correct...or are all?
man on memhog doesn't give any info on the units it displays. Are these
possibly 1024K blocks? If yes, that would get the amount of memory
reported by memhog alot closer to 'ps'. I'm assuming here that u386mon and
ps display in KBytes. Is that correct?
Thanks!
------------------------------------------------------
Ken Wolff
MAXIMUS
Child Support Collection Center
http://www.maxinc.com
Phone: 616-957-4949 Ext: 111
Toll Free: 800-722-2338
FAX: 616-957-1614
------------------------------------------------------
James R. Sullivan
Ken Wolff wrote:
>
> Running OSR505 I can look at a specific process using memhog (from
> Skunk98), u386mon 2.74 and ps and each gives me a different memory size.
>
> memhog shows 1228
If I remember correctly, memhog shows the memory pages, which are 4K
in size. Memhog also takes into account any shared libraries/text
that the process uses and spreads those shared pages across the
various processes that use the shared memory. For instance, if you
had two processes that both used a shared library that used 10 pages
of memory, both process would be allocated 5 pages.
I don't know about u386mon, but the man page for ps(C) is pretty clear
about the output for ps -l:
SZ
THe swappable size (in kilobytes) of the virtual data and stack segments
--
----
Jim Sullivan Wouldn't it be great if gardening was
Manager, SMB Programs just like hockey?
SCO - j...@sco.com
831 427 7108 - Segment Marketing's unofficial motto
Tom Kelly
"James R. Sullivan" <j...@sco.com> writes:
|>
|>
|> Ken Wolff wrote:
|> >
|> > Running OSR505 I can look at a specific process using memhog (from
|> > Skunk98), u386mon 2.74 and ps and each gives me a different memory size.
|> >
|> > memhog shows 1228
|>
|> If I remember correctly, memhog shows the memory pages, which are 4K
|> in size. Memhog also takes into account any shared libraries/text
|> that the process uses and spreads those shared pages across the
|> various processes that use the shared memory. For instance, if you
|> had two processes that both used a shared library that used 10 pages
|> of memory, both process would be allocated 5 pages.
The sizes reported by memhog are in system pages (4K). The vsize
column is the size (in pages) of the virtual address space for the
process. All the other columns are real memory pages.
shrd is the total number of real pages in shareable memory regions
attached to this process. priv shows the total number of real pages
in private memory regions attached to this process. wtd attempts to
account for the actual sharing of shareable regions. As Jim says,
the memory in a shared region is allocated equally among all the
sharing processes; this is the value in wtd.
Total is the sum of wtd and priv, and is intended to measure the process'
impact on the system's real memory.
Having said all that, just looking at a memhog running on my system
the wtd and shared columns are always the same, which suggests to me
that a bug has crept in. (Or that my memory has completely
|>
|> I don't know about u386mon, but the man page for ps(C) is pretty clear
|> about the output for ps -l:
|>
|> SZ
|> THe swappable size (in kilobytes) of the virtual data and stack segments
I wrote memhog partly because ps gives only virtual memory, not real, and I
wanted to look at real memory use.
Tom Kelly
t...@ancilla.toronto.on.ca
Tom Kelly
t...@ancilla.toronto.on.ca (Tom Kelly) writes:
|>
|> shrd is the total number of real pages in shareable memory regions
|> attached to this process. priv shows the total number of real pages
|> in private memory regions attached to this process. wtd attempts to
|> account for the actual sharing of shareable regions. As Jim says,
|> the memory in a shared region is allocated equally among all the
|> sharing processes; this is the value in wtd.
|>
|> Total is the sum of wtd and priv, and is intended to measure the process'
|> impact on the system's real memory.
|>
|> Having said all that, just looking at a memhog running on my system
|> the wtd and shared columns are always the same, which suggests to me
|> that a bug has crept in. (Or that my memory has completely
Well, apparently my memory is so badly shot that having been interrupted
while writing this, I didn't remember that I didn't finish the article.
Sigh.
It appears that the OSR5 memory allocation mechanism has evolved since I
wrote memhog. The sharing mechanism for ELF program code is different;
memhog doesn't detect the shared code for ELF programs and shared
libraries (if you run multiple copies of a COFF program, you'll see
the wtd column and the shrd column with different numbers). This means
that memhog will, unfortunately, overstate the impact of ELF programs
on the system.
--
Tom Kelly
t...@ancilla.toronto.on.ca
Tom Kelly
t...@ancilla.toronto.on.ca (Tom Kelly) writes:
|>
|> It appears that the OSR5 memory allocation mechanism has evolved since I
|> wrote memhog.
In the interests of accuracy, I would like to point out that Larry Philps
did the OpenServer 5 support in memhog.
--
Tom Kelly
t...@ancilla.toronto.on.ca
Tom Kelly
t...@ancilla.toronto.on.ca (Tom Kelly) writes:
|> In article <377f8...@flint.sentex.net>,
|> t...@ancilla.toronto.on.ca (Tom Kelly) writes:
|>
|> |>
|> |> It appears that the OSR5 memory allocation mechanism has evolved since I
|> |> wrote memhog.
|>
|> In the interests of accuracy, I would like to point out that Larry Philps
|> did the OpenServer 5 support in memhog.
This, of course, is intended to give credit where it's due: the changes
to OSR 5 memory management happened after Larry's work on memhog.
--
Tom Kelly
t...@ancilla.toronto.on.ca