Need a good view into shared memory

[Alan Riggs]

I am trying to watch shared memory allocation on a development machine. I can see the segments created with ipcs, and I can write a script to add up the segment sizes. However, this value does not seem to correspond to the value I see in glance - > system tables. (Said value, BTW, sems WAY out of range since it reports more shared memory available than I have on the system in RAM and SWAP combined.)

As a rule, though, when I se two metrics which do not agree I like to nail down why they differ and which one I can rely on. Any suggestions?

[Brian M. Fisher]

Is it possible you have pseudo-swap enabled? This would cause your virtual memory to be greater than real memory + configured swap.

Brian
<*(((>< er

[CHRIS ANORUO]

Understanding Shared Memory on PA-RISC Systems
Document Type MD
Date 1999 Nov 02
Description Understanding Shared Memory on PA-RISC Systems
Document Id RCMEMKBAN00000027
Search String shared memory process

[Alan Riggs]

Thanks for the document search. I amreasonably certain I have a shared memory fragmentation issue. I remain confused, though, about the numbers glance is reporting for shared memory:

Available Requested
95.4gb 1.43gb

The requested value is close, though not identical, to the tabulated results from ipcs. The avauilable number seems absurd for a 10.20 K box with 4GB of physical memory.

[CHRIS ANORUO]

Hi Alan,

Check the value set for SHMMAX in your kernel parameter.

Chris

[Andy Monks]

Alan,

In glance you have the RSS and VSS size. The VSS should always match the size you get from ipcs. The RSS will typically be smaller.

I'm attaching a program that displays all shared resource uses (shmem, mmap, shared lib etc).

It's an unix program really (ignore the .exe bit!)

Run it and it will self-expand into the 'real' program

[SEA RC]

Hi,

ipcs doesn't do such a good job of showing you where the fragmentation in shared memory are. It's a lot more investigative work to find those "holes".

I've got a program attached which can show you the addresses the segments begin with the sizes. You will probably need to map it out on a piece of paper to see where the gaps are, and how big these gaps are.

Good luck!

[Jim Welch · Accepted solution]

Check out the help text for the glance metric TBL_SHMEM_AVAIL. It is basicly just the product of shmmni and shmmmax. It's not really very useful since most people don't have enough swap to really use all the shared memory that they could based on these kernel parmeters. And if the kernel values are very large you can actually overflow the variables used to calculate the number and get some strange results.

Also, if you try to sum up the rss values for processes in glance, remember to check the defination of the proc_mem_res metric. Some versions report the entire value of rss for each process so that if 10 processes shared the same segment and you sum up their rss values, you would count the same segment 10 times. I believe that the scaled the shared memory segments by the reference count in C.02.40 so that will help. But unless you actually go through a memory region loop in your adviser script (or go to the memory regions screen in glance for each process), you do not have an accurate count of memory usage for each process (too much overhead to re-calculate the actual rss every interval by default), so you could still end up with an approximation.

[Alan Riggs]

Thanks to all. I find the calculated value that glance uses to determine shared memory available to be ridiculous when you take into account the 1.75 (2.75) GB limits when running 10.20 (swap space will not let you escape this limit). Truly this is a useless metric.

For those who attached programs, thank you but I am afraid I make it a rule never to run downloaded programs unless I can examine the source code.