topic Re: Additional swap space migration in Operating System - HP-UX

Additional swap space migration

manu_9 — Mon, 17 Jan 2005 00:45:00 GMT

Experts
I have a swap space i(File system swap ) configured in external disk array (SAN) in addition to the primary swap of the machine .I am planning to shift that swap to on eof the internal disks .Please suggest if it would be a wise option to proceed.

Re: Additional swap space migration

Ravi_8 — Mon, 17 Jan 2005 00:55:01 GMT

Hi MANU

Deactivate the file system swap and configuring again using spcae available in internal disk.

using SAM it is very easy, ofcourse the system will reboot twice

Re: Additional swap space migration

Hoang Minh Tuan — Mon, 17 Jan 2005 01:08:17 GMT

Hi,

You can use SAM to check to deactivate your primary swap and it will do it when you reboot the server. You can check swap information by #swapinfo -ta or lvlnboot -v
To add a swap at the end of filesystem by
#swapon -p priority_number -e /dev/dsk/cxtydz (with end of whole disk device)

HMT

Re: Additional swap space migration

manu_9 — Mon, 17 Jan 2005 01:23:39 GMT

Hi,
My question is , Id it a good idea to do this migration from the performance point of view .

Re: Additional swap space migration

Ravi_8 — Mon, 17 Jan 2005 01:44:47 GMT

Hi,

Ofcourse performnace will improve, because for additional swap system no need to look into network (SAN), which is slightly time consuming process than making an I/O to the disk

Re: Additional swap space migration

Hoang Minh Tuan — Mon, 17 Jan 2005 01:47:20 GMT

Sorry for misunderstanding yours.
From the performance's point of view. You should check your performance utilization, indicated by page out by sar -w, vmstat, how your Physical memory is and how local space disk. If it's not take much memory , you should take it by default (it mean that lvol2 as primary swap)

HMT

Re: Additional swap space migration

Trond Haugen — Mon, 17 Jan 2005 06:26:45 GMT

You should check with 'swapinfo -tam' to see if swapspace is actually being used on SAN.
If nothing is used you will not gain any performance.
If swapspace is used on SAN you will get better performance by moving it to local disk. You will get better performance because:
1. It is local (vs SAN).
2. it is device swap (vs filesystem swap).
If posible you should put it on another disk than the promary swap and give it the same priority (given the speed of accessing the disks are the same).

Regards,
Trond

Re: Additional swap space migration

Florian Heigl (new acc) — Mon, 17 Jan 2005 06:46:02 GMT

Performance should increase as long as Your local disks aren't too slow, also deviceswap is considered much faster than filesystem-based swapfiles.
Furthermore, when swap usage is high, it might steal performance from the data-filesystems on the SAN.

If Your local reserve to 'eof' in vg00 is really large, You will have to check the kernel parameter max_swap_chunks, or the system possibly won't able to use it to full.

Also... are You sure You don't want to keep any reserve in vg00 for emergencies?

Personally, I'd add the swapspace right now and update fstab so that the next scheduled reboot cleans up the things.

lvcreate -l 1 vg00
lvextend -m 1 /dev/vg00/
lvchange -m y /dev/vg00/ #one might argue that one, decide Yourself, don't just use it.
lvextend -l /dev/vg00/

# enter swapspace to fstab
# please use a lower priority than the already-existing swapspace in vg00, or the disks get hammered without gain
/dev/vg00/ ... swap pri=2 0 0
swapon -a

# then remove the filesystem swap from /etc/fstab

good luck :)

Re: Additional swap space migration

Bill Hassell — Mon, 17 Jan 2005 08:33:42 GMT

There will be virtually no performance change no matter how fast or slow your swap devices might by (well, floppies might be an issue...). Swapping, even to a RAM disk will be slow. It requires that processes be deactivated and then selected pages of the these processes be rolled out to the swap area, while pages for the higher priority process be moved into memory. Swapping at high rates (dozens of pages per second) inidcates a severe shortage of RAM and faster swap areas won't fix the problem.

Now it's true that filesystem swap is slower than a raw swap area and it's certainly a good idea to use a raw lvol as secondary swap space rather than sharing it with a filesystem. But check to see whether the swap space is actually being used (swapinfo -tm). The secondary swap area should a higher priority number (less important) than your primary swap. If they are equal then swap space is allocated in a round-robin method.
But if you look at vmstat's statistic: po (which is page outs), single digit numbers are fine, double and triple digits for long periods will need more RAM to significantly improve performance.