Memory required by a process (core and virtual)

[Andrea Pagani]

'top' man page reports these definitions:

(SIZE) Total size of the process in kilobytes. This includes text, data, and stack.
(RES) Resident size of the process in kilobytes. The resident size information is, at best, an approximate value.

These sentences are not so clear to me:
1) I don't understand if, for SIZE, total means core (loaded in RAM) plus virtual memory or only total portion of core memory owned by the process;
2) What resident means? Does it mean not swappable? Why is it an approximate value?

Are there other means to investigate process' memory needs (I 'd like to determine the total size of memory and swap space required by a process)?

[John Palmer · Accepted solution]

Hi Andrea,

SIZE is the Virtual Size of the process i.e. the sum of the size of all its segments or the amount of memory it would require if it was all loaded into RAM.

The Resident Size is the amount of memory actually held in RAM.

As to why it is approximate, I guess because the Resident Size can vary rapidly as a process runs. Pages will get paged in and out depending on the needs of the process and others. A process can also allocate/deallocate memory as it runs.

The HP-UX Memory Management White Paper can be found on an 11.00 system in /usr/share/doc - mem_mgt.ps or .txt.

Glance has comprehensive facilities for monitoring process memory regions but it is a purchasable option although well worth it in my opinion.

Hope this helps,
John

[Don Morris_1]

SIZE as reported by top is _only_ the virtual size of text+data+stack. Note that this is _not_ the total virtual size of a process (uareas for threads, shared libraries and some other stuff isn't counted in text+data+stack).

Resident size == Private physical pages for the process (translation: how much of the process is actually in memory that isn't shared with other processes). It's approximate for one thing because top gets this stuff from pstat, which is only updated about once a second... and doesn't exactly use a fine
grain algorithm.

The fun thing about this is that RES can easily be > SIZE, which is fairly counter-intuitive when you read that man page. Consider a process where all text, data, and stack pages are not swapped out (not a rare thing). RES then is SIZE + uareas + privately mapped shared memory segments + whatever else goes in there that I'm forgetting.

Moral of the story? Use top for coarse grained trends. Otherwise, as John pointed out, glance is much better.