memory leak - script to compare output

[Anchal Nigam]

I wrote a little script to compare the output of the below command to see if a certain process is using more memory. I was hoping some of the HP gurus here could give me some feedback.

UNIX95= ps -e -o ruser,vsz,pid,args

To use it, run the command and save the output to a file. After a while, run it again and save the output to another file. Run the script by passing the file names as paramaters (first-run first, then second run).

./compare_ps.pl mem.one mem.two

The columns are:

- PID : PID of process
- DFFF : Numerical difference
- DIFF % : Difference in %
- ONE MEM: The memory used for the process on the first run
- ONE COMMAND: The process command
- TWO MEM: The memory used for the process on the second run
- TWO COMMAND: The process command

I added the ONE COMMAND and TWO COMMAND columns to confirm it is the same process.

The script will not show processes unless:

- the PID exists on both runs
- memory usage for a process is not 0
- memory usage for a process is not the same on both runs
- the commands for a process on both runs is the same
- the % difference is not less then 1 (memory usage decresed)

Any thoughts?

[James R. Ferguson · Accepted solution]

Hi:

You don't offer what process (or kind of process) you are attempting to monitor; nor why. Do you believe you have a problem?

Focusing on process "data" as opposed to a process's stack or "text" (instructions), even if a process 'free()'s memory that it has 'malloc()'ed, that memory isn't returned to the operating system at large until the process terminates. Rather, the 'free'ed memory is returned to the 'heap' where it is available again to 'malloc'. By design, the goal is to minimize some of the overhead of memory allocation/deallocation.

Thus, you generally won't see the memory of a running process shrinking over time.

The maximum size of the heap is governed by the kernel fence 'maxdsiz' or 'maxdsiz_64bit' for 32-bit and 64-bit processes, respectively.

You can examine some of a heap's characteristics with 'mallinfo()' [see the manpages for 'malloc'].

Another problem with measuring a process'es memory footprint is the accounting of shared memory among various processes and/or shared libraries. Do you accord shared components to every process sharing them or not count them at all? Different tools may provide different views and values.

Regards!

...JRF...

[Anchal Nigam]

@James R. Ferguson: I am not sure about any of that. I am relativly new to all this. My HP-UX 11.11 system is showing these errors in /var/adm/messages:

sysmap_64bit: rmap ovflo, lost [3636915,3636917)
sysmap_64bit: rmap ovflo, lost [3636913,3636914)

I was told the below command can be used to track down what process is responsible.

UNIX95= ps -e -o ruser,vsz,pid,args

??

[James R. Ferguson]

Hi (again) :

See Don Morris's comments in this thread:

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

Read, too, the link he references, which points to the kernel tunable 'nsysmap'.

Regards!

...JRF...

[Michael Steele_2]

Hi

Well you almost got it, very close.

UNIX95=1 ps -ef -o vsz,pcpu,pid,ppid,state,args | sort -rn | head -15 > $OUTFILE

Run in cron every 15-20 minutes. You are looking for stable and static of which 95% will be, or growing in vsz.

Let it run for 2-3 days.

[Dennis Handly]

If you really have an application memory leak in addition to that rmap ovflo kernel message, you can use wdb's heap checking commands.