Pin Memory Statistics

Hi,

We have an issue on our lpar where the pin memory usage slowly and regularly increases approx 1.5% a day until it reaches its 80% threshold
We have to regularly reboot the lpars to release the pin memory as we have found that killing all processes does not release it.

However, obviously this is not a real solution.

I have monitored any constantly running processes that increase in memory usage with time by monitoring the output of ps vg. The only one I found of any significance was xmwlm stats recording service which I stopped, but pin memory usage still increased at the same pace.

Is monitoring svmon -P going to help me find the cause of this issue and if so, monitoring which figure in following example of a process when running svmon -P, will show me the process is increasing in pinned memory usage to cause the increase we are seeing. I know the obvious answer would be 'the one that says pin above it' but there are three of them in the example.

Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 16MB
53274 wait 12251 8399 0 12251 Y N N

PageSize Inuse Pin Pgsp Virtual
s 4 KB 12155 8319 0 12155
m 64 KB 6 5 0 6

Vsid Esid Type Description PSize Inuse Pin Pgsp Virtual
0 0 work kernel segment s 12155 8319 0 12155
2802e f00000002 work process private m 5 4 0 5

Many thanks for any answers.

It is obvious you have an application with a memory leak. Complain with the softwares makers, whoever it may be. This is not acceptable.

Have a look at "ipcrm" and "ipcs" ("man ipcrm", "man ipcs"), it is probably not necessary to reboot the system.

Good try. Maybe "ps -Alo pid,comm,vsz" will serve you better in this case. Sort the output for column 3 to get the top memory users.

The 3 distinct statistics shown by "svmon -P" are just different views of the matter. Use the number in the first part, it is for your purposes as good as the others. The first part is the overview, the second part shows the utilization of the different memory page sizes and the last part is a detailed list of memory statistics for the process' inner workings. You won't need that just to identify a memory hog.

I hope this helps.

bakunin