Add additional swap place on AIX server

Can anyone help me the detailed procedure and commands to follow to add additional swap on aix server .

My system shows following as of now ,

#lsattr -E -l sys0 -a realmem
realmem 13893632 Amount of usable physical memory in Kbytes False

#pstat -s
PAGE SPACE:

          USED PAGES   FREE PAGES
           735534       837330

# lsps -a
Page Space      Physical Volume   Volume Group    Size %Used Active  Auto  Type
hd6             hdisk0            rootvg        6144MB    47   yes   yes    lv

Please help me on finding what is the maximum swap size that i can increase? Also i need to do it without a reboot.Thanks

The maximum theoretical size of one paging device is 64 GB. You have paging device hd6 which is 6 GB. Theoretically you can expand it by 56 GB.

Before expanding you have to answer the following questions:

• how much memory does your application require?
• is it possible to buy more memory, if the LPAR doesn't have enough, or to move it to another server?
• how did it happen, that you have 47% used in paging space? Which processes are now in the paging space and which of the running processes overuse the memory resources you have?

After you answered the questions and if you still want to have more paging space, you can look in rootvg using lsvg rootvg , if you have enough space in the volume group, and then create additional paging space with mkps or expand the existing with chps .

agent.kgb is absolutely correct: paging space is a "plan B", if "plan A" (memory) fails. Your system shouldn't need to use it under normal circumstance and it should be there only for contingency.

Right now you have your 13GB memory already overused to a point where ~3GB of paging space is needed. You should put in more memory (unless other data show different probably ~5GB, to cover for the 3GB already missing and some extra on top to make the system comfortably run) and only then make your paging space bigger.

The size of paging space should be in some relation to the real memory, like the size of a jerry can should reflect the cars gas consumption. And like the jerry can it should be there but under normal circumstances never be used.

I hope this helps.

bakunin

It would also be interessting when the paging to PS occurs. I saw that RMAN accumulated used pgsp at nightly backup jobs (over some days/weeks) but on days peak loads had about no paging out at all.
You can monitor this by writing a small script using vmstat to have a look at the pi/po columns or have nmon installed to record it for you.

Depending on the oslevel of your OS it could also maybe handled by adjusting some tuning parameters.

If you want to investigate what is using the paging space at the moment you can issue:

svmon -P | awk '/Pid/ {a=$0; getline; if($5 != 0) {print a RS $0}}'

Column 5 shows which processes have allocated pgsp.

Hello All,

Thank you for your help. I checked the physical memory being only 13GB and left the idea of increasing swap size as of now.
I will get back in case of any progress.

Just an additional info - if you don't get all processes listed, try adding ALL to svmon like:

svmon -P ALL| awk '/Pid/ {a=$0; getline; if($5 != 0) {print a RS $0}}'

zaxxon,

not every segment in AIX memory has a corresponding process.

The real command to look, what lays in paging space is something like:

svmon -S -O sortseg=pgsp -t 20

-S shows all memory segments, -O sortseg=pgsp sorts them, showing first the segments which have most pages in the paging space, -t 20 shows only first 20 segments.

This is an example from a system, which pages right now:

$ lsps -a
Page Space      Physical Volume   Volume Group    Size %Used Active Auto  Type Chksum
hd6             hdisk0            rootvg        8192MB    24   yes   yes    lv     0
$ svmon -S -O sortseg=pgsp -t 20
Unit: page

    Vsid      Esid Type Description              PSize  Inuse   Pin Pgsp Virtual
  8f61ff         - work mmap paging                 sm      0     0 65024   65024
  86078c         - work                             sm    127     4 64405   64451
  838405         - work mmap paging                 sm    762     0 64336   65024
  820fc6         - work mmap paging                 sm   2521     0 62703   64770
  847dc9         - work mmap paging                 sm  13881     0 54286   64032
  825b45         - work                             sm     24     0 14056   14075
  8c97db         - work                             sm    224     4 10339   10475
    8000         - work page table area              s   6916    43 6873    6916
  81de02         - work                             sm   3362     0 4965    6645
  82dd04         - work                             sm   2491     0 4285    5952
  8d4e5b         - work                             sm     65     4 3694    3747
  8e841d         - work                             sm    535     0 3473    3677
  8c9f59         - work                             sm    603     0 2611    2791
  820b66         - work                             sm    287     0 2588    2619
  8c58f9         - work                             sm   3443     0 2428    3497
  884951         - work mmap paging                 sm   8192     0 2186    8192
  8c1b3a         - work                             sm     48     4 2082    2101
  825965         - work                              m   4096     0  124    4096
    1001         - work other kernel segments        m    149     0  123     235
  8d001a         - work                              m    194     0  115     272

As you see, all the segments are "work" segments and some of them has "long" Vsids (virtual segment IDs), such as 8f61ff, but some of them has "short" Vsid, such as 8000. Those with long IDs are probably associated with some processes. You can look at them using the following command:

$ svmon -S 8f61ff -lrj

    Vsid      Esid Type Description              PSize  Inuse   Pin Pgsp Virtual
  8f61ff         - work mmap paging                  s      0     0 65024   65024
                                                     m      0     0    0       0
                   Addr Range: 0..65534
                   pid(s)=12058694

The last string contains pid, which you can then find with ps -ef :

$ ps -ef | grep [1]2058694
    root 12058694 16973956   0   Feb 01      - 320:07 /opt/ibm/node/bin/node /kibana/src/cli

If you look at a segment with short Vsid, you will not see any pid:

$ svmon -S 8000 -lrj

    Vsid      Esid Type Description              PSize  Inuse   Pin Pgsp Virtual
    8000         - work page table area              s   6916    43 6873    6916
                   Addr Range: 0..8703
                   System segment

It is a system segment and it has no corresponding process. Sometimes they can grow very big and in this case it is not an application problem, but server's configuration problem.

I think for a first shot to help the OP the command is sufficient. Thanks for your additional info though.