What is the Command to monitor process memory usage

[rymani]

The "top" command is showing the memory usage status of processes, but it is not showing the memory getting down whenever a deallocation occurs (c++ delete operator), whereas in windows i can able to see the memory getting down when deallocation occurs using "task manager".

Whether "top" is not the right command to monitor memory, if so any other command is there for to monitor memory.

[Ludovic Derlyn]

hi

Use glance to monitor it
glance->process list-> select process (S)
You can see memory by process

Regards
L-DERLYN

[Don Morris_1 · Accepted solution]

Actually, top is probably right (and I doubt Glance will show things much differently). A deallocation in C++ / free() in C gives memory back to the underlying library (libc in C, I haven't worked in C++ for 7 years so forgive me if I forget that library name). The library then does caching or garbage collection or whatever it wants to do [usually just the caching -- if you deallocate a C++ object and then ask for a new one... you can get the memory you just freed back]. As a result, from the OS's point of view (which is what top/Glance is reporting), the application memory consumption didn't change -- because the library per-application caches are already included in those values.

Only when the library layer decides to give memory back to the underlying OS will you see the application shrink. Windows libraries may just do that more aggressively, is all. For the Unix libraries, they're likely (I say this because I certainly didn't write all the libc / libc++ variants out there by any means) more worried about virtual address space management than physical. First, there's no guarantee an object of a particular size touched all the underlying pages anyway, and second -- the OS will page out objects in the application or the library (since it neither knows nor cares where the library thinks the ownership is) if it needs/wants more memory anyway. Only the virtual address layout/limitations of the application itself matter... and the caching benefits outweigh (strongly in most cases) the overhead of tossing memory down to the OS layer on every free().

[H_16]

GlancePlus - Graphical interface....

#export DISPLAY
#gpm


You will be able to see memory usage more clearly..

[Geoff Wild]

How about this script called processmem:

# /usr/local/bin/processmem lpsched


Memory claimed by lpsched: 12772 Kbytes.


# cat /usr/local/bin/processmem
#!/bin/sh
# processmem - display memory claimed by a process
#
if [ $# -lt 1 -o \( $# -gt 1 -a $# -lt 4 \) ]
then
echo "Usage:"
echo "processmem \"process\""
echo "Example:"
echo "processmem rpc"
exit 1
fi
echo " "

PROCESS=$1

mps=0
#for sz in `ps -elf | grep $PROCESS | grep -v grep | awk '{print $10}'`
for sz in `UNIX95= ps -e -o vsz=Kbytes -o ruser -o pid,args=Command-Line | sort -rnk1 | grep -v Kbytes | grep $PROCESS | awk '{print $1}'`
do
mps=`expr $mps + $sz`
done
#echo `expr $mps \* 4096`
echo "\nMemory claimed by $PROCESS: $mps Kbytes.\n"

Rgds...Geoff

[A. Clay Stephenson]

Except in rare cases (newer versions with correct options set and if the block is essentially the last allocated), HP-UX (like most UNIX flavors) does not return the free()'ed memory to the OS but rather pushes the deallocated memory onto the heap for subsequent reuse by the same process. It is thus very rare for a process to shrink in size. UNIX ain't Windows; don't expect Windows-like behavior.

The underlying system call, sbrk(), does allow a negative "growth" and thus it is possible to shrink memory BUT using sbrk() means that you take full control of memory allocation and do not use malloc(), calloc(), realloc() et al or constructors that allocate memory. The execeptions I alluded to earlier do change the behavior of free() to see if the block is the last on the heap and if so will do a negative sbrk() --- but that is the exception.

[Don Morris_1]

You can also get true free behavior (either in the library layer or in your own application if you really want to write your own memory management layer) using MAP_ANONYMOUS|MAP_PRIVATE mmaps. Either unmap the pages, mprotect them with PROT_NONE, etc. when they are completely free. You have to have some sort of metadata to represent sub-page object free counts, of course...

sbrk() is doable, but much less flexible. [You can have holes in the heap with the private mmap() model in a manageable fashion... let the OS worry about refilling the holes for you when you map a new object, etc.]

[Dennis Handly]

As everyone as mentioned, when you delete (which by default calls free), the space is just left on the libc heap free list. You can call mallinfo(3) to get the used and free sizes.

>Clay: et al or constructors that allocate memory.

If you define your own operator new/delete, you can do anything you want to allocate/deallocate memory. Even use mmap private as Don suggested. For STL containers, you can define your own allocator class.

[rymani]

Thanks everyone for your valuable suggestion.