7

Possible Duplicate:
Linux: How to measure actual memory usage of an application or process?

Why I use 'top' in Linux to show my memory of one process,I get that the storage of the process do only increase and do not decrease except I close the all process.I don't know why,though I use 'free' only behind 'malloc'. How can I get the correct actual REAL-TIME storage of my process? thanks all.

Community
  • 1
  • 1
keyoflov
  • 103
  • 1
  • 6
  • Do you want to get the memory usage of that process via C API from within your program which could be that process or via a shell command? – Dan D. May 02 '12 at 06:55
  • I get from the shell command 'top' that the my C process is taking more and more storage of the OS when I take some actions,and I know that I have 'free' all the 'malloc'. – keyoflov May 02 '12 at 07:17
  • this should be a comment not an answer i think – Sam Holder May 02 '12 at 06:58
  • @Sam, yes, but sebif is just two points away from being able to post comments... – sarnold May 02 '12 at 06:58
  • ... and now, enough that you can re-post this as a comment. :) – sarnold May 02 '12 at 06:59

5 Answers5

8

find the pid, if its running as the same user, use "ps aux", otherwise use "ps ax", then execute this:

cat /proc/<PID>/status

this should be all u want to know.

K1773R
  • 922
  • 4
  • 10
6

The short answer is that on a modern operating system this is very difficult.

Memory that is free()ed is not actually returned to the OS until the process terminates, so many cycles of allocating and freeing progressively bigger chunks of memory will cause the process to grow. (via)

This question has been already answered in more detail on another SO thread. You might find your answer there.

Community
  • 1
  • 1
Lee Hambley
  • 6,270
  • 5
  • 49
  • 81
1

Depending upon the size of your allocations, your memory may or may not be returned to the OS. If you're allocating large things (see MMAP_THRESHOLD in malloc(3)), things that take many pages of memory, glibc will use mmap(2)'s MAP_ANONYMOUS flag for the allocation; when you free(3) this object, glibc can return the page to the OS, and your memory usage will go down.

You can tune MMAP_THRESHOLD down using mallopt(3) if you wish.

If you have many smaller allocations, your memory may be fragmented enough that free(3) cannot actually free up an entire page that could be returned to the OS. You might have relatively little in use on a given page, but the entire page is still allocated against your process, and it replaces an entire page's worth of data from other processes.

sarnold
  • 102,305
  • 22
  • 181
  • 238
0

I don't think that this other question really answers this in detail.

Adding to what sarnold says, it could be helpful to free() in the opposite order as malloc() - especially for the smaller memory chunks. Then the heap can shrink again from the end...

In order to verify that, you should, in a test program, call void *sbrk(intptr_t increment); with an increment of 0 - then it tells you the current value of the heap - and output it in order to see its changes. If you do it correctly and in the right oder, the glib should call brk() to increase the heap and eventually shrink it again.

Community
  • 1
  • 1
glglgl
  • 89,107
  • 13
  • 149
  • 217
0

You can try pmap and the id process:

    1:   init [3]

001c3000 100K r-x-- /lib/ld-2.5.so

001dc000 4K r-x-- /lib/ld-2.5.so

001dd000 4K rwx-- /lib/ld-2.5.so

001e0000 1256K r-x-- /lib/libc-2.5.so

0031a000 8K r-x-- /lib/libc-2.5.so

0031c000 4K rwx-- /lib/libc-2.5.so

0031d000 12K rwx-- [ anon ]

0034b000 8K r-x-- /lib/libdl-2.5.so

0034d000 4K r-x-- /lib/libdl-2.5.so

0034e000 4K rwx-- /lib/libdl-2.5.so

006f2000 236K r-x-- /lib/libsepol.so.1

0072d000 4K rwx-- /lib/libsepol.so.1

0072e000 40K rwx-- [ anon ]

0073a000 84K r-x-- /lib/libselinux.so.1

0074f000 8K rwx-- /lib/libselinux.so.1

00fff000 4K r-x-- [ anon ]

08048000 32K r-x-- /sbin/init

08050000 4K rw--- /sbin/init

09c0f000 132K rw--- [ anon ]

b7fed000 8K rw--- [ anon ]

bfd87000 84K rw--- [ stack ]

total 2040K

Serx_Mz
  • 39
  • 4