Originally posted by: Holgervk

Hello,

can somebody tell me how to find out what processes have so much memory pinned?
This is an oracle-server, however, currently oracle isnt running.

root@sbcluava01:/root > svmon
size inuse free pin virtual
memory 31457280 12933320 18523960 11283358 12568915
pg space 27262976 121037

work pers clnt
pin 11283077 0 281
in use 12532671 0 400649

PageSize PoolSize inuse pgsp pin virtual
s 4 KB - 12203512 110093 10816622 11834851
m 64 KB - 45613 684 29171 45879

root@sbcluava01:/root > ps -ef|wc -l
162
root@sbcluava01:/root > svmon -Ppt3

---

Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 16MB
25677874 hatsd 78000 69728 336 78026 N Y N

PageSize Inuse Pin Pgsp Virtual
s 4 KB 2512 2384 0 2234
m 64 KB 622 113 21 641

Vsid Esid Type Description PSize Inuse Pin Pgsp Virtual
0 0 work kernel segment (lgpg_vsid=0) L 16 16 0 16
ad70ad d work shared library text m 622 113 21 641
fc04fd 2 work process private s 1532 1520 0 1532
17cbf7d f work shared library data s 613 613 0 613
1850984 1 clnt code,/dev/hd2:61774 s 242 203 - -
f32cf2 - work s 27 27 0 27
1f4f1f6 - work s 60 19 0 60
620863 - work s 1 1 0 1
1620963 - work s 1 1 0 1
2a662b - clnt /dev/hd9var:518 s 1 0 - -
330a32 - clnt /dev/hd9var:509 s 7 0 - -
1190918 - clnt /dev/hd2:50725 s 28 0 - -

---

Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 16MB
1011912 hats_nim 76058 67873 336 76314 N Y N

PageSize Inuse Pin Pgsp Virtual
s 4 KB 570 529 0 522
m 64 KB 622 113 21 641

Vsid Esid Type Description PSize Inuse Pin Pgsp Virtual
0 0 work kernel segment (lgpg_vsid=0) L 16 16 0 16
ad70ad d work shared library text m 622 113 21 641
a608a7 f work shared library data s 284 284 0 284
1cc75cd 2 work process private s 213 201 0 213
1b909b8 1 clnt code,/dev/hd2:61841 s 44 37 - -
a4d0a6 - work s 25 7 0 25
ef88ee - clnt /dev/hd9var:560 s 2 0 - -
1920993 - clnt /dev/hd9var:441 s 2 0 - -

---

Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 16MB
12820654 hats_nim 76061 67873 336 76314 N Y N

PageSize Inuse Pin Pgsp Virtual
s 4 KB 573 529 0 522
m 64 KB 622 113 21 641

Vsid Esid Type Description PSize Inuse Pin Pgsp Virtual
0 0 work kernel segment (lgpg_vsid=0) L 16 16 0 16
ad70ad d work shared library text m 622 113 21 641
165217 f work shared library data s 284 284 0 284
1670966 2 work process private s 213 201 0 213
1b909b8 1 clnt code,/dev/hd2:61841 s 44 37 - -
127213 - work s 25 7 0 25
1530d52 - clnt /dev/hd9var:549 s 1 0 - -
13de93f - clnt /dev/hd9var:489 s 6 0 - -
#AIX-Forum

Originally posted by: DLLuner

SVMON, in my experience, doesn't usually lie. AIX does pin what one may view as large amounts of memory for reasons such as potential I/O to potential DLPAR operations. Check to see your LPAR's MIN/MAX/DESIRED settings. Do you have a large number of devices assigned/configured? Have you greatly up device queue depths? AIX needs to handle worse case, so the larger your delta the more pinned memory.

I suppose it's possible that someone pinned a segment and then went away. You should be able to use SVMON to find large (and pinned) segments and then trace back to the (probably kernel) processes that are attached to them. It's possible that Oracle pinned some memory and didn't release it, but check the amount of pinned memory on a "freshly booted" system.
#AIX-Forum

Originally posted by: gcorneau

If they're running Oracle RAC with GPFS this might also be the GPFS pagepool memory that's pinned. Look for an "mmfsd64" process and run "svmon -P <pid>" against it to see if that's the culprit.

---

Glen Corneau
IBM Power Systems Advanced Technical Support
#AIX-Forum

Originally posted by: MarkTaylor

man svmon

-p Indicates that the information to be displayed is sorted in decreasing order by the total number of pages pinned.

HTH
Mark Taylor
#AIX-Forum

Originally posted by: Casey_B

Hello Holgervk,

What I can tell you from the output that you gave is that you have HACMP/PowerHA installed.

The processes listed belong to the RSCT daemons (specifically the topology services daemons)
They are meant to be pinned into memory.

Although those processes are using the most per process pinned memory, they do not appear to be using
a large part of the whole...

Hope this helps,
Casey
#AIX-Forum

Originally posted by: Holgervk

I really wonder why there are so many pinned kernel segments.
Can anybody comment on this?

root@sbcluava01:/root > svmon -Spt 40

Vsid Esid Type Description PSize Inuse Pin Pgsp Virtual
260226 - work other kernel segments s 65536 65536 0 65536
20002 - work other kernel segments s 65536 65536 0 65536
280228 - work other kernel segments s 65536 65536 0 65536
0 - work kernel segment (lgpg_vsid=0) L 16 16 0 16
57005 - work vmm software hat s 65536 65536 0 65536
230223 - work other kernel segments s 65536 65536 0 65536
2e022e - work other kernel segments s 65536 65536 0 65536
240224 - work other kernel segments s 65536 65536 0 65536
250225 - work other kernel segments s 65536 65536 0 65536
2c022c - work other kernel segments s 65536 65536 0 65536
290229 - work other kernel segments s 65536 65536 0 65536
270227 - work other kernel segments s 65536 65536 0 65536
2d022d - work other kernel segments s 65536 65536 0 65536
2b022b - work other kernel segments s 65536 65536 0 65536
2a022a - work other kernel segments s 65536 65536 0 65536
2c102c - work kernel heap s 65510 65510 0 65510
4a104a - work kernel heap s 65507 65507 0 65507
691069 - work kernel heap s 65507 65507 0 65507
2000 - work mbuf pool s 65504 65504 0 65504
581058 - work kernel heap s 65502 65501 33 65502
5a105a - work kernel heap s 65498 65498 113 65498
6a106a - work kernel heap s 65493 65493 0 65493
681068 - work kernel heap s 65488 65487 15 65488
571057 - work kernel heap s 65506 65485 19 65506
6b106b - work kernel heap s 65485 65485 0 65485
871087 - work kernel heap s 65487 65483 0 65487
861086 - work kernel heap s 65489 65483 2 65489
7a107a - work kernel heap s 65496 65481 73 65496
561056 - work kernel heap s 65484 65474 12 65486
781078 - work kernel heap s 65501 65466 90 65502
491049 - work kernel heap s 65487 65464 21 65488
671067 - work kernel heap s 65490 65463 13 65491
591059 - work kernel heap s 65489 65459 40 65490
51005 - work kernel heap s 65443 65443 0 65443
6c106c - work kernel heap s 65444 65436 7 65444
661066 - work kernel heap s 65462 65421 29 65467
471047 - work kernel heap s 65443 65409 25 65447
2a102a - work kernel heap s 65322 65306 11 65322
2d102d - work kernel heap s 65306 65306 0 65306
791079 - work kernel heap s 65470 65256 28 65475
#AIX-Forum

Originally posted by: Holgervk

It seems that I am facing

http://www-01.ibm.com/support/docview.wss?uid=isg1IZ05462
http://www-01.ibm.com/support/docview.wss?uid=isg1IZ16399

Look at output of perfpmr.sh

===========================================================================
Detailed Memory Components | Pages | Megabytes
----------------------------------------------------|----------|-----------
Light Weight Trace memory | 245760 | 960.00
LVM Memory | 349856 | 1366.62
Total Kernel Heap memory | 9529847 | 37225.96
JFS2 total non-file memory | 5924759 | 23143.58
metadata_cache | 947387 | 3700.73
inode_cache | 2142432 | 8368.87
fs bufstructs | 8360 | 32.65
misc jfs2 | 2826580 | 11041.32
misc kernel heap | 3605088 | 14082.37
Total file memory | 5073241 | 19817.34
Total clnt (JFS2, NFS,...) file memory | 5073241 | 19817.34
Total pers (JFS) memory | 0 | 0.00
Total text memory | 76353 | 298.25
Total clnt text memory | 76353 | 298.25
Total pers text memory | 0 | 0.00
#AIX-Forum

Originally posted by: Stefano Cavaliero

lauch this command

svmon -D 0

and see if the result is the same that i post:

Segid: 0
Type: working
PSize: L (16 MB)
Address Range: 0..15
Size of page space allocation: 0 pages ( 0.0 MB)
Virtual: 16 frames ( 0.1 MB)
Inuse: 16 frames ( 0.1 MB)

I want to investigate on this problem, and i think that was a bad addressing of the large page from a process that do an allocation of only 16 frame instead of 16Mb.
#AIX-Forum