memory leackage

[csd_1]

How can I know any memory leak
ipcrm with idno can remove memory leak but how we know which memory causing problem
when I was trying to recover file system using frecover but it does not work then i did ipcrm oracle id i found with ipcm command then it work but i was not sure about the id, but can we know there any leakage.

Regards

CSD

[Steve Steel]

Hi


You can see memory used with ps

/bin/rm /tmp/$PPID 2>/dev/null
UNIX95= ps -e -o ruser,vsz,pid,args > /tmp/$PPID
head -n 1 /tmp/$PPID
tail -n +2 /tmp/$PPID|
sort -rnk2
/bin/rm /tmp/$PPID 2>/dev/null

Will give processes by memory usage.

If one process grows it is leaking.


steve Steel

[csd_1]

Thanks for your response I got like this from this how I know oracle process have leackage

Regards

CSD

applcrp1 30212 27866 oracleCRP1 (LOCAL=NO)
applcrp1 30212 27858 oracleCRP1 (LOCAL=NO)
applcrp1 30212 27850 oracleCRP1 (LOCAL=NO)
applcrp1 30212 27834 oracleCRP1 (LOCAL=NO)
applcrp1 30212 27810 oracleCRP1 (LOCAL=NO)

[harry d brown jr]

csd,

Processes cause memory leaks, not physical memory itself. Along with Steve's suggestion, use glance to "drill" into potential offenders.

Also, make sure you have the latest Patches for your OS and your applications.

live free or die
harry

[Rainer von Bongartz · Accepted solution]

If you suspect a memory leak you should do the following:

check the size of your processes

You can get the top virtual memory usage processes like this:
UNIX95= ps -e -o ruser,sz,vsz,pid,args | sort -rnk3 | head -3

If they stay constant you dont have a memory leak in user space.
There might still be a meory leak in the kernel.

check this with kmeminfo. If you dont't have kmeminfo download PHCO_20262. This contains kmeminfo.

Regards
Rainer

[Bill Hassell]

Your problem is with shared memory, not a memory leak. Shared memory will become fragmented as you start and stop various processes and fbackup/frecover use shared memory. However, when Oracle or frecover request shared memory, there must be enough contiguous space to hold the requested segment. While there may be plenty of shared memory, none of the pieces are large enough.

This problem is associated with 32bit applications and can only be fixed by stopping all the processes using shared memory and then restarting them in a specific order. You'll need to read the white papers on memory management and process management which are found in /usr/share/doc. Also get a copy of shminfo so you can see the fragmentation:

ftp://contrib:9unsupp8@hprc.external.hp.com/sysadmin/programs/shminfo/