Interpreting kmeminfo (and memory usage)

[David G. Douthitt]

I'm attempting to interpret the details from kmeminfo, but what I see (in summary) is this:

Physical Memory = 18.0g
Free memory = 2.3g
User procs = 6.9g
System = 4.6g

Which leads to:

4.6 + 6.9 + 2.3 = 13.8g

What happened to the other 4.2g? And why am I only getting 7g or 8g out of 18g for user procs?

[Laurent Menase]

kmeminfo is a support only tool.
Contact hp support

[Bill Hassell]

Memory usage is much more complex than user and system. The only (easy) way to see all memory usage is with Glance. kmeminfo is not showing you shared memory, shared libraries, the buffer cache, I/O space, etc.

> And why am I only getting 7g or 8g out of 18g for user procs?

That's because your programs have not asked for more memory. A process must ask for more memory and for sophisticated programs, you can usually edit a configuration file that will use more RAM.

[Venkatesh BL]

Interesting. What is the OS version? What does the 'percent' column say?

On my 11.23, I see:
Physical memory = 35584246 135.7g 100%
Free memory = 28870327 110.1g 81%
User processes = 1389740 5.3g 4% details with -user
System = 5234925 20.0g 15%

...which adds up just fine!

But, please understand that it is not a 'supported' tool.

[David G. Douthitt]

Operating system is 11.31 64bit IA64; current reporting on this system is:

Physical = 18.0g (100%)
Free = 1.9g (11%)
User procs = 7.2g (40%)
System = 4.6g (26%)

1.9 + 7.2 + 4.6 = 13.7

Glance is reporting:

Physical: 18.0g
User: 8.4g
Sys: 4.5g
BufCache: 0.0g
Free: 2.1g
FileCache: 3.0g

8.4 + 4.5 + 2.1 + 3.0 = 18.0

kmeminfo also seems to be reporting user process memory differently than glance - it comes up with larger numbers overall.

I pulled kmeminfo from a forum posting; using v5.19.

Let me rephrase my question that is driving this ("name the problem"): Does HP-UX have to use 4+Gb? Is that too big? Is 8Gb user space out of 18Gb reasonable? How do I increase memory available for user-space processes? And (by extension) - how will an increase of memory be utilized? Will it all be available to user space?

[David G. Douthitt]

One more question (hoo boy): And why am I seeing swapping going on with 70%-80% memory usage according to glance?

[Don Morris_1]

Well, I don't remember just how far back 5.19 is. It may not fully understand 11i v3 (the current major number is more than a bit higher for the tool).

It would help immensely if you'd post the entire Summary output instead of paraphrasing it. That would help identify just what it is seeing vs. what it isn't on a v3 system. It would also give some idea of what is really under the "System" category (I know what about 8 to 9% is going to be, but there's a lot of variability for the rest).

To your direct questions:

1) There's no way to know if HP-UX _has_ to use 4Gb to accomplish your workload, though I suspect the answer will be "probably, or at least at some point it did" with the data given. I can tell you that the kernel doesn't go spuriously allocate memory just because it feels like it... but as always, various tunable settings and your given workload will play into System consumption. v3 has a base cost of around 8 to 9% to get up and running, though... so around 1.7Gb is required minimally for your 16Gb system.
[For example -- what if your workload requires a heavy network load? This may all be networking buffers of various sizes... that incoming data has to go somewhere. Or if it is a file intensive workload working on many, many files it might be all the inodes in memory...]

2) Swapping? (As in process deactivation?) Are you sure? How are you determining this?

If by swapping you really mean "paging" where some pages are flushing out of the system -- that is more likely than not just the File cache doing its job. (v3 unified the old mmap cache and the Dynamic Buffer Cache... the filecache_min / filecache_max tunables control the size -- and the vhand daemon may page pages from the cache to the files if they're dirty to adjust the size -- if you aren't under pressure and are seeing Glance report "page outs" it is very likely it is simply the file cache adjusting down via vhand...).