topic Re: high sys mem in Operating System - HP-UX

high sys mem

Kenan Erdey — Thu, 14 Dec 2006 04:49:59 GMT

hi;

we have hp-ux 11.11 machines with the same hardware properties. all kernel parametres are same. but when i look at "sys mem" from glance, one's is shown 1.3 gb whereas others' go around 800mb. what can be the problem ?

thanks.

Re: high sys mem

Peter Godron — Thu, 14 Dec 2006 04:59:30 GMT

Hi,
"Sys Mem: The amount of physical memory KBs unless otherwise specified) used by the system (kernel) during the interval. System memory does not include the buffer cache.
On HP-UX 11i and beyond, this metric does include some kinds of dynamically allocated kernel memory."

"Glance showing sys mem very high - whats using it ?"
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=68965

Please also read Doc KBRC00011764
at: http://www4.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000079989625

Re: high sys mem

Kenan Erdey — Thu, 14 Dec 2006 07:19:48 GMT

hi again;

when i run kmeminfo it gives an output:

Physical memory = 2096640 8.0g 100%
Free memory = 529644 2.0g 25%
User processes = 327085 1.2g 16% details with -user
System = 1233669 4.7g 59%
Kernel = 342894 1.3g 16% kernel text and data
Dynamic Arenas = 128220 500.9m 6% details with -arena
M_TEMP = 87228 340.7m 4%
M_SPINLOCK = 6769 26.4m 0%
ALLOCB_MBLK_LM = 4624 18.1m 0%
KMEM_ALLOC = 3552 13.9m 0%
VFD_BT_NODE = 3185 12.4m 0%
Other arenas = 22862 89.3m 1% details with -arena
Super page pool = 1651 6.4m 0% details with -kas
Static Tables = 185612 725.0m 9% details with -static
nbuf = 87968 343.6m 4% bufcache headers
pfdat = 47683 186.3m 2%
htbl2_0 = 16384 64.0m 1%
inode = 8203 32.0m 0%
pfn_to_virt = 7947 31.0m 0%
Other tables = 17426 68.1m 1% details with -static
Buffer cache = 890775 3.4g 42% details with -bufcache

in other servers, M_TEMP value is around 50mb. any ideas ?

Re: high sys mem

Mark Nieuwboer — Thu, 14 Dec 2006 07:48:33 GMT

Hi Kenen,

What kinf of sotware do you run on the boxes.
In my experience java is many times the bad boy for system memory.

grtz. Mark

Re: high sys mem

Mark Nieuwboer — Thu, 14 Dec 2006 07:49:45 GMT

forget my post did not read the problem.

grtz. Mark

Re: high sys mem

Kenan Erdey — Thu, 14 Dec 2006 08:27:50 GMT

yes, oracle ias is running. and an application is running written in java.

Re: high sys mem

John Guster — Thu, 14 Dec 2006 11:21:43 GMT

kmtune|grep adb, to see if MAX and MIN are identical on both servers. And swapinfo -mat to check if both has the same amount of swap space configured.

Re: high sys mem

Don Morris_1 — Thu, 14 Dec 2006 11:23:10 GMT

Do kmeminfo -arena M_TEMP. It may simply be that you had a memory spike and there hasn't been sufficient memory pressure to warrant full garbage collection of the arena.

If its all/mostly in use, it would be hard to track down without just TOC'ing the box and sending in the dump for analysis (which I wouldn't think would be worth it). M_TEMP is used by a lot of different clients for well, temporary allocations. [We've strongly encouraged folks move away from it in later releases because of just this sort of scenario where you can't really know what used the memory easily]. Almost all of them should be short lived, hence why I'm expecting to see a sizable percentage of this as free, simply indicating you had a spike in some sort of kernel usage (SysV semaphores, lots of pstat calls, etc. can give this sort of result -- but that's just the short list off the top of my head).

Re: high sys mem

John Guster — Thu, 14 Dec 2006 11:23:14 GMT

sorry, it should grep dbc===dbc_max_pct anf dbc_min_pct are two parameters to check in kmtune command.

Re: high sys mem

Kenan Erdey — Fri, 15 Dec 2006 03:12:31 GMT

it can be fully irrelevant, some time ago this machine gave a lot of messages like "dev/vg00/lvoloradata file system full (1 block extent)". can it be that some process fill the memory while trying to write ?

Re: high sys mem

Bill Hassell — Fri, 15 Dec 2006 08:06:53 GMT

> "dev/vg00/lvoloradata file system full (1 block extent)". can it be that some process fill the memory while trying to write ?

No, the only portion of memory affected by reads or writes to files is the buffer cache and it is not associated with M_TEMP. One of the many uses of the M_TEMP area is for the JFS inode cache, but only for JFS ver 3.3 and 11.11. Upgrading to JFS 3.5 will move this cache to the vx_icache_arena. Note that this won't significantly reduce kernel memory, it just moves it to a new location. It's possible that intense network activity may cause the M_TEMP area to grow. The real problem in reducing M_TEMP is locating all the possible uses as it is just an internal miscellaneous temp area. Because effort to truly track down all the usage is enormous and in your case, the amount of RAM is only a few hundred megs, it probably isn't worth the effort.