HPUX 11.23 - System memory seems high.

[KennethMRay]

On this 11.23 system with 12GB of physical memory system (kernel) memory seems high. System memory used is 7.3GB and User Mem is 3.7GB and Buf Cache is currently at 367MB.

Any idea why system memory would be so high? Is there a way to examine the kernel memory usage to see where the high utilization might be?

Could it be a leak of sorts?

Thanks,

[Ganesan R]

Hi,

System memory 60% is unusual.

Check the value of dbc_min_pct and dbc_max_pct which defines the buffer cache. Default dbc_max_pct value is 50%. reduce to 10-15% depends upon your requirement.

Use kmeminfo tool to find more details about memory usage.

[UVK]

System mem utilization is generally very low but again it depends on ur way ur system is built and the application running on it.

Its also a possibility that application memory leaks to cause this.

[KennethMRay]

DBC MIN/MAX set to 2/3 respectively. So they are low hence the low BUF CACHE used I mentioned above.

Well there is a Cache DB running on this server. Is a leak possible to show up under System Memory Usage?

Where can I get an up to date version kmeminfo to check out the kernel?

Thanks,
Ken

[Steven E. Protter]

Shalom,

dbc_max_pct controls the buffer pool. Setting it to a high figure causes two issues:

1) The memory is unavailable to the system.
2) Changing the system buffer pool figure is very expensive in terms of CPU.

Because of item two, you want dbc_min_pct and dbc_max_pct to be very close if not identical.

In versions of HP-UX before 11.23 Oracle got no benefit from the buffer pool, therefore I would set it low.

Part of performance tuning is finding a buffer pool figure that works with your applications.

SEP

[Ganesan R]

Hi,

Just call HP if you have contract, and you can get the latest version of kmeminfo.

I would suggest you to involve HP if you have software contract and let HP provide the analysed report.

[KennethMRay]

Like I mentioned their set to 2/3 and that is quite low. Also, system memory is depicted aside from DBC that has it's own metric.

So, in order to get off the dbc cache tangent.

Is anyone familiar with high kernel memory usage this is quite high and doesn't allow for much memory free/available. I think if I could examine what the kernel is using it would be quite beneficial.

[Viktor Balogh]

here is a memory leak detector script to monitor memory usage:

http://www.hpux.ws/?p=8

[Armin Kunaschik · Accepted solution]

Get the kmeminfo tool and run it with "-arena" option.
You get output similary like this:

Dynamic Arenas:

Variable arena "M_TEMP" owns 1778844 pages (6.8gb):
Free objects represent 23.7mb (0%) of all memory in this arena.
idx objsz pages bytes % nobjs used free %
0 24 1766553 6.7g 99 222585678 222584672 1006 0


If the M_TEMP arena is bigger that 100MB and has many small pages allocated, then you need to install PHKL_38436.
Reason is a kernel memory leak when hardware monitoring is enabled. See more detail in the patch description.

My 2 cents,
Armin

PS: Please assign points if you find answers useful!

[KennethMRay]

Here is my kmeminfo output and I was just investigating the M_TEMP area...very large.

Variable arena "M_TEMP" owns 1446160 pages (5.5gb):
kmem_arena_t 0xe00000011c008780
Attributes: KMT_DEFAULT KT_DEFAULT KAS_ALIVE
Per index summary (all cpu's):
idx objsz pages bytes % nobjs used free %
0 24 1436988 5.5g 99 181060488 181060225 263 0
1 56 13 52.0k 0 819 342 477 58
2 120 49 196.0k 0 1519 532 987 65
3 184 4 16.0k 0 84 8 76 90
4 248 2585 10.1m 0 38775 18681 20094 52
6 376 1 4.0k 0 10 1 9 90
7 440 4 16.0k 0 36 0 36 100
8 568 3905 15.3m 0 27335 18454 8881 32
11 952 4 16.0k 0 16 0 16 100
12 1336 5 20.0k 0 15 3 12 80
13 1976 1 4.0k 0 2 1 1 50
14 4024 5 20.0k 0 5 1 4 80
16 8192 8 32.0k 0 4 0 4 100
23 36864 2588 10.1m 0 287 287 0