Total memory of a process

[ahpuser]

Hello,

My environment is HP-UX B.11.11 (11i v1) on a HP-9000 machine.

I have a java application and need to know two things:

- The amount of physical memory (RAM) that the process is using.
- The total size of memory (physical + paged out = Virtual Address Space) that the process is using.

I have read that the memory used by a process is allocated in 3 sections:

1) Plain memory (data + stack + code (text)).
2) Shared memory
3) Memory mapped files (mmap)

I have read also that the java heap is allocated inside the mmap section. Is it true?
It's important, because in a Java application, normally the java heap is the largest part.


I have used the ps command like this:
# UNIX95= ps -efo vsz,sz,pid,args | grep java

And the output is:
47164 11535 5254 /opt/java1.5/bin/PA_RISC2.0/java -Xmx1024m com.interop.telecron

From the HP-UX command reference (http://docs.hp.com/en/B2355-90690/ps.1.html):
Column sz: The size in physical pages of the core image of the process, including text, data, and stack space.
Column vsz: The size in kilobytes (1024 byte units) of the core image of the process. See column sz, above.

So I think that vsz is equivalent to sz but in kilobytes instead of pages.

sz = 11535 pages (4 KB each, I suppose)
vsz = 47164 Kilobytes = 46.05859375 MB

It seems that the size reported by ps don't include the shared memory and mmap sections size.


I have used the top command and the output is:

CPU TTY PID USERNAME PRI NI SIZE RES STATE TIME %WCPU %CPU COMMAND
0 ? 5254 root 152 20 1407M 123M run 10:37 2.59 2.59 java

From the HP-UX command reference (http://docs.hp.com/en/B2355-90690/top.1.html):
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.

By the documentation I would think that the SIZE column should be equal to the vsz column from the ps command, but that's not true.

What is reporting the SIZE column?
What is reporting the RES column?
Those values include shared memory and mmap sections?


Finally I have read that there are two metrics called RSS and VSS but can't find any documentation that explain what are those.

Is RSS the TOTAL physical memory (RAM) used by the process?
Is VSS the TOTAL memory (physical + paged out = virtual address spacce) used by the process?

How can I find those values?

Thank you very much.
Any help would be greatly appreciated.

[James R. Ferguson]

Hi:

> So I think that vsz is equivalent to sz but in kilobytes instead of pages.

See Don Morris' discussion here:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1267952

It seems that the size reported by ps don't include the shared memory and mmap sections size.

Simply using 'ps' to calculate how much memory a process uses is an exercise in rough estimates. Shared memory, program text (for multiple instances of a particular process) and shared libraries contribute to the "count" in an "un-fair" way since they can't be apportioned to just one instance.

The 'glance' tool is one of the best HP-UX tools for a "fair" accounting of memory consumption on a process basis. The tool allows selecting and drilling into lots of information on a per-process basis.

Regards!

...JRF...

[ahpuser]

Thank you for the reply

> See Don Morris' discussion here:
> http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1267952

I have read the discusion, so let me see if I understand it right:

sz = Number of pages that are resident in RAM. This memory only includes code + data + stack.
vsz = Number of kilobytes that are resident in RAM + Number of kilobytes that are in disk (swap region). This memory only includes code + data + stack.

Is that correct?

> The 'glance' tool is one of the best HP-UX tools for a "fair" accounting of memory consumption on a process basis. > The tool allows selecting and drilling into lots of information on a per-process basis.

I don't have glance and definitely can't install it.

Is there a standard tool that can show the total resident and the total virtual memory of a process?

Thanx

[Dennis Handly]

>Is there a standard tool that can show the total resident and the total virtual memory of a process?

Why do you care about resident? This varies with the load.
You can use pstat_getprocvm() to get all of the memory segments in the process.

[ahpuser]

From the thread: http://forums12.itrc.hp.com/service/forums/questionanswer.do?threadId=1276005

Steven E. Protter wrote:
> 1) vsz virtual memory size (allocated) from swap
> sz memory size (allocated)

> 2) SIZE is program memory size
> RES is amount resident memory.

Sorry about my ignorance, but I don't understand clearly. Could you give a little more detail please?

Please correct me if I'm wrong: A process have a virtual address space. This address space contains (or points to) all the data the program can use.

The virtual address space contains (or points to):
The program code (text), data, stack.
The O.S. required libraries.
The shared libraries required to execute the program.
A mmap section to map files.
Etc.

Some part of the virtual address space is loaded in RAM, wich is called resident. I'm right?

The rest of the virtual address space is not in RAM, but in disk (the swap region).

So the questions are:

1) What is reported by the ps command in the sz column?

2) What is reported by the ps command in the vsz column?

3) What is reported by the top command in the SIZE column?

4) What is reported by the top command in the RES column?

5) What is reported by the glance tool in the VSS parameter?

6) What is reported by the top command in the RSS column?

Thanks

[ahpuser]

Sorry, question 6 should say:
6) What is reported by the glance tool in the RSS parameter?

[Dennis Handly]

>A process have a virtual address space. This address space contains (or points to) all the data the program can use.

Yes. And this can change during the process.

>The program code (text), data, stack.
>The shared libraries required to execute the program.
>A mmap section to map files

Yes.

>Some part of the virtual address space is loaded in RAM, which is called resident. I'm right?

Yes. But why are you concerned about this issue? If you have performance problems, you add more memory. If you are doing number crunching where you need more VM that you can possibly install RAM, then you worry.

>The rest of the virtual address space is not in RAM, but in disk (the swap region).

Yes and this varies depending on the system load.

>So the questions are:

What are you going to do with any answers?