How to find root cause of memory leak hpux 11.11

[James R. Ferguson]

Hi Frank:

You note that "only recently have we had this". Is something or someone perchance killing (with 'kill -9') a process that uses shared memory? This would include 'fbackup' sessions. If so, the shared memory segments would be left lying around, consuming precious resources.

Regards!

...JRF...

[Don Morris_1]

That version of kmeminfo is beyond stale... it is simply an old script that was handed out with other Q4 tools. It pretty patently doesn't work [properly/completely] on your system -- so if you must use kernel intrusive tools, ask your support contact for a recent version. (I expect your kernel Dynamic data is non-zero and that's an important thing to know).

Getting back to the question at hand -- are you sure this is a leak in the first place? What exactly do you mean by "swapinfo shows PCT 60% or more"? If that's just reservation -- this is to be expected. You started Oracle, it presumably made some SGAs... but you didn't have client processes accessing it. As they start to -- they consume virtual address space, hence reserve swap... the load increases, the swap reservations increase... if the load decreases, the swap reservations will return.

Similarly -- HP-UX is *designed* to cache RAM for performance. The system will not be at all aggressive about reclaiming free memory in these caches (and there are several -- Buffer Cache, kernel dynamic memory arenas, etc.) when memory is above the lotsfree value (which is roughly 1%. 100Mb is about 2.44% of 4Gb, hence I wouldn't expect things to be reclaimed aggressively yet.

Doing a bit of math and trusting that that old kmeminfo isn't completely wrong on what it does recognize -- Total minus User minus DBC is 224560. Subtracting Static and Free -- that gives about 181251 pages for Kernel Dynamic or about 708Mb. Not unreasonable for a system under light pressure running Oracle.

So -- it looks like your big knob if you're really concerned is the buffer cache. And since that would naturally fill up as the system gets used, that may be your perceived leak in the first place -- you could set dbc_min_pct and dbc_max_pct to the same value to prevent buffer cache growth (it would prereserve the min and then just recycle those pages). As mentioned, if Oracle is doing direct I/O anyway, a smaller buffer cache is likely better for you anyway. At the least keeping the buffer cache static would give you some idea if this is your perceived leak, though I still would expect free memory to drop towards 1% and stay there in the common case.

[Laurent Menase]

If you want to use kmeminfo you should probably get a newer one.

The one you have looks to be an old one working on 11.0 only.....

but looks like you should reduce your buffer cache ( dbc_max_pct) . it is using 30% of the memory currently

[Frank de Vries]

Thanks , some good replies ,
I changed max_dbc_pct , which was 50%.
So I consider that a solution for now.

And I started to run UNIX95 at regualar intervals, so I wil see what comes out.

I didn't find the comments about kmeminfo not that relevant. To me Kmeminfo responded well to the kernel par change I did.

Tough allocating points on this one :)

[Dennis Handly]

>Bill: you can only see a memory leak after you establish what is normal (after a reboot).

The reboot is probably true for a kernel leak. But an application leak can be seen by restarting the application.
And using a leak detection tool like gdb.