Summary:How to know the real memory of a process?

From: Xu Zhimin <xuzm_at_ns.cetin.net.cn>
Date: Fri, 01 May 1998 11:54:30 +0800

Thanks to so many people who respond rapidly.

The general answer were :

---
        Using free() frees the memory segment to be used again, but it
is still maintained by the process.It
doesn't free it to the operating system. This could be considered as a
process overhead. There are no definite
methods for finding the exact memory being used by a process at a given
instance.
        There are certain options which can be used but they may not be
very effective/clean. There is a variable called noshrink ( check man
pages on free() ) which can be set to force freeing of memory. There are
some other functions like brk() and sbrk() that can be used too.
       Another way of checking could be by running another memory
intensive process. While the first process frees mem., run another
process which requires a lot of memory. This might force the rssize of
the first process to show the exact mem usage. But this would be
effective only if a lot of mem is being freed by the first process.
---
You are assuming, incorrectly, that when you "free" memory in your
program
that was obtained through the libc "malloc" call, it's really returned
to
the system.  That is not the case.  You can "grow" the memory allocated
to
your process through the "malloc" interface, and if the library routines
need more, they will use the "sbrk" system call to get more (if
possible).
But when you "free" the memory, it is just marked available to the
library,
not returned to the system.
Unless the system as a whole is starved for memory (you're paging things
out
because the combined resident set sizes of the running processes exceeds
the
available physical memory), the RSS of a running process will rarely
shrink,
because a running process rarely really discards pages.
---
First, RSSIZE is measuring what's in *physical* memory.  It can change
without any assistance from the program (for example, if the program is
swapped out it goes to 0).  However, for an application that is
enthusiastically using memory without paging or competition from other
applications it's a reasonable measurement.  A more accurate measurement
would be VSZ (sp?), the virtual size.  This includes space that is not
currently in physical memory.  It also includes shared memory - so if
several
processes are sharing the same memory, you can't add up their VSZ values
to
get a total - the shared memory would get counted more than once.
Second, free only tries to return memory to the system under certain
specific
conditions.  In particular, only if it is freeing a large block which
lies
at
the end of the address space will it try to return the memory to the
OS.  I
don't remember exactly how big the block has to be, but it's on the
order of
several K of memory.  This means that even a few allocated blocks here &
there can tie up all the memory the process is using so none of it is
returned to the OS.  If the user is *sure* that they've freed all their
memory this is probably not a problem though.  They can use the Heap
Analyzer
to check for leaks, and the Memory Profiler to see what memory is still
allocated.
Third, currently the OS ignores attempts to return memory to it from a
process until the process exits.  It turns out that a lot of processes
do
this and then ask for the memory back again, and it's faster to not
actually
return the memory.  I don't know if there are any plans to change this.
So, the conclusion is that the RSSIZE output from ps is probably
correct, due
to the other aspects of the problem, the total virtual memory use is
probably  not going to go down.
---
     Someone talked about   the files  existing at /proc filesystem.
     The name of those files are the PIDs of the process runing in the
     system and the size of that "virtual files" is the size of the
process
     image. For example :
     ROOT >
     ROOT > ls -l /proc
     total 3767168
     -rw-------   1 root     system   680534016 May  7 12:55 00000
     -rw-------   1 root     system     8527872 May  7 12:55 00001
     :
     :
     :
     -rw-------   1 root     system     8519680 May  7 12:55 29225
     -rw-------   1 root     system    29327360 May  7 12:55 30054
     -rw-------   1 root     system    28745728 May  7 12:55 30064
     -rw-------   1 root     system    28745728 May  7 12:55 30067
     -rw-------   1 root     system    28745728 May  7 12:55 30115
     ROOT > ps -fea | grep 30115
     root     30115 30054  0.0 22:16:15 ??           0:00.67 sdaemon -c
8
     root      6921  4257  0.0 12:55:48 ttyp0        0:00.00 grep 30115
----
My original question was:
> Dear Manager:
>     I want to know the real memory size of a process.
> I used the command "ps -o rssize -p pid". But I found that
> RSSIZE of the running process only grow  in size, never shrink,
> even after I freed the  allocated memory in my program. why?
>     Are there any other ways to know the real memory size of a
> running process?

Received on Fri May 08 1998 - 04:23:01 NZST