lvextend primary swap

[Alex Georgiev]

Has anyone out there increased primary swap by doing an lvextend on the LV?

I am going to do this soon, and I am just wondering if I should expect any problems? I am also wondering if the new space becomes available automatically, or will it take a reboot?

My primary swap is /dev/vg00/lvol2, as is usual. I do have enough free contiguous extents, I am armed with an Ignite-UX tape (or two), and I am familiar with the lvlnboot command. Running 11.11 on the server in question.

I am looking for some of the not-so-obvious or subtle problems, or any "battle" stories from the field where a lesson was learned.

Thanks much!

[JASH_2]

Alex,

You cannot extend primary swap, without re-installing the operating system, because the first three filesystems need to be contigeous. There are get-arounds, but these are not supported by HP.
A better way to do this would be to create an additional disk swap. You may need to increase the maxswapchunks kernel parameter to accomodate the extra swap.

Hope this helps,

JASH

[RAC_1]

You can not. And you just do not need to do that. Add addiotional swap space (secondary swap) Create new lvol (preferrablly on seperate disk than the primary swap disk)
lvcreate -C y -r n /dev/vgxx

Make sure you have kernel tunable maxswapchunk set right. Then just pu this swap device in use.

swapon -av

Put it in fstab to make it swap space at boot time. Like. follows.

/dev/vgxx/lvolx ... swap pri=x 0 2

priority should be same as primary swap. This in turns makes swapping round robin and is good.

[Kent Ostby]

If you've added RAM and that's the reason you are extending swap, then make sure you add the new swap partition to the dump setup via crashconf.

So if your new swap partition is /dev/vg00/newswap then do:

crashconf /dev/vg00/newswap

[AwadheshPandey]

If you want to increase swap space then you should take a ignite backup and then re-install from ignite tape and it will give option to increase the size of swap. this is the way you can increase ur primary swap. you can also increase ur systems swap by adding another file system swap. SAM is the best way to add swap space.

see the doc attached for more info.

Cheers,

Awadhesh

[A. Clay Stephenson]

You are going to a great deal of trouble to do something that is not necessary. I never configure systems with large amounts of primary swap; typically only the minimum. It's so easy to add addiotional swapspace that it's not worth worrying about. Your additional swapspace doesn't even have to be in vg00. No reboot is required; all you need to do is make create an additional LVOL, make an /etc/fstab entry, and run the swapon command. The addional swap space will automatically be used on the next reboot without having to explicitly run swapon. The only reason that a reboot might be required is that maxswapchunks might need to be increased which would require a kernel build. This would be true if primary swap were enlarged or addional secondary swap were added. One of your standard practices should be to set maxswapchunks as large as you ever expect to need when the system is initially set up.

[Alex Georgiev]

Ok, well... I know that the majority of you said "you can not" but I did do it the way that I had planned it. And... Yes, I probably did more work than necessary, but it works for me. Keeps vg00 nice and clean.

So, here are the overall steps I took:

1) I took time, in advance, to shuffle disk space on my system drives. That included breaking some mirrored LVs, a few pvmoves(1m), even creating a temporary "stub" logical volume, and finally reestablishing the mirrors.

2) Ultimately I ended up with this physical layout at the beginning of the system disks:

lvol1
lvol2
contiguous free space
lvol3
other LVs

At this point all LVs were mirrored between two system drives. I had even ran lvlnboot -R, even though that is supposed to run automatically after every pvmove(1m) affecting vg00.

3) At that point I did an lvextend on lvol2:

lvextend -l /dev/vg00/lvol2

4) lvol2 simply took the available contiguous free space, no questions asked

5) The system did not automatically recognize the newly available swap space

6) I rebooted, and the system swap & dump was now bigger

I would NOT recommend this process to anyone inexperienced with LVM. The complicated part is in the first step: shuffling things around on the system disks. If anyone is really curious, I can posts the steps I took.

There is also a great deal of risk involved, because you don't really know how the system will react when lvol2 suddenly becomes bigger. I would not be doing this on a system with high swap utilization - at least not at runlevel 3, maybe go to single user mode first.

As far as just adding a 2nd swap space... In my opinion there is one problem with that: I will end up with two swap spaces that are NOT next to each other on disk - one will be at the beginning of the disk (lvol2) and another at the end (the new swap volume). From what I understand, this is not a good idea from a performance stand point. I am sure that there is a reason why primary swap has to be contiguous. By creating a new swap space I will essentially break up the contiguity.

Maybe I am way off on that last point, so if you do not agree, please reply. Do tell me why having two swap spaces at different physical locations on the same disk is OK. Thanks!


P.S. I do realized that I could have saved myself the reboot by simply creating a new LV in the contiguous free space behing lvol2, and using that as the new swap. This was only a matter of personal choice.

[Bill Hassell · Accepted solution]

You mentioned:

> As far as just adding a 2nd swap space... In my opinion there is one problem with that: I will end up with two swap spaces that are NOT next to each other on disk - one will be at the beginning of the disk (lvol2) and another at the end (the new swap volume). From what I understand, this is not a good idea from a performance stand point. I am sure that there is a reason why primary swap has to be contiguous. By creating a new swap space I will essentially break up the contiguity.

Back when memory was measured in megs (not gigs), swap space was a critical part of the OS and swap performance was a big issue. So big, that Unix would define the importance of swap areas (priority) and use round-robin for equal priority. Having swap spaces close together was of some importance, decades ago.

Today, swap is the worst possible feature of a virtual memory machine. Application users cannot tolerate the massive delays caused by deactivating processes, then moving pages out to swap areas. The impact is so damaging to performance that disk performance and contiguous space is simply unimportant. When more RAM is needed by a top priority program, other programs are deactivated as the available memory approaches zero. Once the amount of RAM is too small, portions (pages) of the program(s) are moved to swap. But because memory is being reorganized, spinlocks will occur, effectively stopping all activities on all processors until the new memory layout is stabilized. This affects all processes and users on the system at the same time.

The key is the swap rate...a handful of pages per second is not usually noticed, dozens of pages will make the system seem sluggish, and hundreds of pages will make your server run like a Windows XP system with 64megs of RAM (ie, 15 minutes to boot up, 5 minutes to start Excel).

Now that's not to say that a highly interactive system won't benefit from swapping. When there is a lot of "think" time, applications can easily be deactivated and paged out in a small RAM system because the time needed to reinstate the process is relatively short. I ran about 2000 users on a 256meg system where 90% of the work was elm and LaserROM (aka, Instant Information). Active swap space usage was over 2000 megs but the page out rate was 1 to 5 pages/sec average. No one noticed.

But a modern database works much differently. There is a large coordination program that gets and puts the data from small clients. If the main program is too large to fit into RAM, it will be constantly paging and everyone would feel the pain.

So "swap performance" is an oxymoron -- it is a conflict in terminology in today's computers. Just add swap space as needed from any volume group. You won't be able to measure any difference whether the swap is on a big VG00 primary and 10 different areas scattered all over your disk farm. If you start using the swap space at a high rate, your users (and managers) won't care about your swap layout -- the only fix is more RAM.

[Alex Georgiev]

Well put! Are there any other opposing views?

[A. Clay Stephenson]

Not at all. I always say that worrying about swap layout is akin to rearranging the deck chairs on the Titanic. If your box begins to swap (page out) to any significant degree, you've already lost the battle. In your case to (as you put it keep vg00 clean), I would have simply added another swap LVOL in vg00 (and if on the same physical disk as your primary swap I would have set its priority different from 1 -- but even that's rearranging the deck chairs) and declared victory. The difference is that I would have been done in about 2 minutes and your "improved" method I suspect took much longer -- and both would be equally effective.

[Alex Georgiev]

Yeah, yeah! Rub it in, rub it in! :-)

Agreed, it doesn't make sense to spend 2 hours rearranging vg00 and then rebooting... unless you are a perfectionist, or you have an older machine with a slow system disk and a small amount of RAM.

On the bright side, I proved to myself that primary swap can be extended.

Thanks for the replies! I think we beat this one to death.