Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Burst vs VSwap vs Swap
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Burst vs VSwap vs Swap

CoolMoonCoolMoon Member
edited January 2013 in Help

Not quite sure what are the differences between these terms on VPS. Here is my understanding which might be terribly wrong. So please feel free to correct me.

For example:
128MB guaranteed with 256MB Burst:
the max physical RAM you can actual use is 256MB, although it depends on whether the host node has enough free RAM to allocate the other 128MB.
128MB guaranteed with 128MB VSwap:
although the VSwap shows under "swap" in "free -m", actually it is still in the physical RAM of the host server. the container is just artificially slowed down to emulate the "swap" effect.
128MB guaranteed with 128MB swap:
the "real" swap is a portion of the hard drive, will only be used when your physical RAM is not enough.

So my understanding is:
if you are using 100MB RAM, everything is in physical RAM in all 3 cases, so performance-wise, Burst = VSwap = Swap
if you are using 200MB RAM, Burst (everything still in physical RAM) > VSwap (everything in physical RAM but slowed down) > Swap (start to rely on disk I/O). Not sure if this is correct because I have no idea to which degree the VSwap will be slowed down. But I guess VSwap should still be better than "real" swap which get HDD involved.

Then what's the advantage for VSwap over Burst?

Comments

  • jhjh Member
    edited January 2013

    Your understanding is correct.

    @CoolMoon said: Then what's the advantage for VSwap over Burst?

    It's guaranteed (supposedly, though in fact the provider can oversell it as well). Consider the VPS host selling 2GB RAM servers for a pittance. There isn't going to be a lot of space for you to 'burst'. That's nothing new though - you get what you pay for.

    As for standard SWAP - it's ill-advised to run them on standard disks as it deteriorates them quickly. Ideally a quality provider will be using SSDs for SWAP partitions.

  • I think the VSwap kernels are less fucky with memory allocation than Burst as well. MySQL, for example, doesn't take up nearly as much RAM on a vSwap VPS compared to Burst.

  • jhjh Member

    @ihatetonyy said: I think the VSwap kernels are less fucky with memory allocation than Burst as well. MySQL, for example, doesn't take up nearly as much RAM on a vSwap VPS compared to Burst.

    Another problem I forgot to mention - a lot of software tries to make the best use of memory available and since it 'sees' the burstable memory as available where in fact is isn't, the software can end up crashing due to a lack of memory.

  • jarjar Patron Provider, Top Host, Veteran
    edited January 2013

    A computer doesn't have a memory allocation that it likes you to use, and then another 50% that it prefers that you don't use. Burst, if sold correctly, might as well be called "total allocated memory." A system without swap is not normal. Swap is part of the package, it is not normal to have 0 swap. Thus the introduction of vSwap. This is RAM that, when used, causes the container to artificially slow down to simulate the effects of swap on a normal machine without effecting other containers on the host node.

    The advantage is that many applications are not designed to run without swap. If you don't have swap, many applications will use more memory. The benefit of one over the other would, at best, depend on the task. The benefit of vSwap is that more applications will work as intended, today and tomorrow. The benefit of burst, hard to say. I don't see a benefit other than a perceived financial one. If you think you're getting 512 for the price of 256, you're not. Your provider is charging you for 512. Personally, I think it's easier to sell 256 of that as vSwap for less than 256 of it as burst, because if your container is slowed, ultimately I expect your resource usage will as well.

  • Is the provider able to set how much the VSwap slows your node down, or it is totally controlled by the kernel?

  • @jhadley said: It's guaranteed (supposedly, though in fact the provider can oversell it as well)

    So if a VPS comes with 128MB RAM + 128MB VSwap, supposedly the system will guarantee you 256MB RAM in total all the time??

  • jarjar Patron Provider, Top Host, Veteran
    edited January 2013

    @CoolMoon said: Is the provider able to set how much the VSwap slows your node down, or it is totally controlled by the kernel?

    They are not.

    @CoolMoon said: So if a VPS comes with 128MB RAM + 128MB VSwap, supposedly the system will guarantee you 256MB RAM in total all the time??

    Just as 256mb with 256mb burst should. Though this guarantee must be met with some question, as overselling memory is equally as normal in both situations.

    I guess, in theory, my summary should be this:
    Burst usage of 512mb would outperform usage of 512mb if 256mb were vSwap. However, on a vSwap system, your usage would often be lower in general, therefore requiring more usage to reach 512mb of memory used than on a system without swap. For most of us it doesn't really matter because we stay under our allotment anyway. But the point is that the two are not interchangeable terms and they do work differently.

  • krokro Member

    No swap + no ram left=dead applications

  • CoolMoonCoolMoon Member
    edited January 2013

    It seems using the command "free -m" alone could not tell if one VPS is a 256 with 512 burst, or 512 without any burst. Same thing for 256 with 256 VSwap, or 256 with 256 real swap. Is there any other command to check the RAM type?

  • jarjar Patron Provider, Top Host, Veteran
    edited January 2013

    It's always ram. There is no real disk based swap with openvz. Either vSwap or no swap. For reference, output /proc/user_beancounters. Burst is privvmpages. Swap is swappages.

  • No overselling I think VZ is better.

  • VSwap handles RAM better that's about it.

    I'm not sure why but I have a node on .18 kernel and running perfectly, no downtime for the past 60 days. Then there's another one that is running on a .32 Kernel and has a reboot every week. (Hardware is all new, even been replaced twice).

    @CoolMoon said: VSwap over Burst

  • @rffan said: No overselling I think VZ is better.

    Can still oversell with VSwap

  • What I read before is you can use whatever bean counters are letting you use.

  • Anybody knows "how much" vSwap is slowed down? I wasn't able to find out any numbers about this. If its nearly as slow as HDD swap, a larger amount of vSwap would be a bit waste of RAM, or not?

  • @Синтия last time this question arised, nobody had an exact answer: http://www.lowendtalk.com/discussion/3143/openvz-burstswap
    But seems like the slow-down isn't really significant. At least in real environment.

  • jarjar Patron Provider, Top Host, Veteran

    I have clients using all of their memory and vSwap, I've not had a complaint about slow containers. Seems that the answer would be easily found, but none of us care enough to find it. Personally I don't much care because my answer would be what it always is when you're hitting swap...get more memory ;)

  • shovenoseshovenose Member, Host Rep

    I think that vSwap is the best.

  • @nstorm: Thank you for the link. I was just surprised that there seems no further information about the slow down behavior.

    @jarland: But it would be interesting to really know what you get with that vSwap...

  • @Синтия interesting nickname. Written in cyrillic yet i don't think it's a Russian or slavic name.

  • Cynthia? @rds100

  • @Amitz yes, only this one is written in cyrillic.

  • @Синтия said: Anybody knows "how much" vSwap is slowed down? I wasn't able to find out any numbers about this. If its nearly as slow as HDD swap, a larger amount of vSwap would be a bit waste of RAM, or not?

    It's an algorithm that considers:

    -the amount of guar ram the container has
    -the amount of swap the container has
    -the amount of guar ram minus cached ram in use
    -the amount of swap in use

    And the method it uses for 'slowing down' the container is to delay disk i/o AND reducing cpuunits dynamically.

    Basically, if the container is using all of it's guar ram, but not for cache, it will begin to artificially slow down disk i/o and reduce the cpuunits that the container has been assigned.

    If the container is using all of it's guar ram, but most of it is for cache, ovz realizes that some processes think they need swap, so it does not arbitrarily slow down the container.

    If you need more input on this, let me know, and I can find the exact function in the source for you.

  • @rds100: right, it's not a russian name, originally it cames from greek ;)

  • СинтияСинтия Member
    edited January 2013

    @damian: thanks a much for your description!
    With disk i/o you mean i/o of the vSwap?

  • nstormnstorm Member
    edited January 2013

    @Синтия I guess he means the whole disk i/o. Like with real swap on the same hdd - when its swaps out, your whole i/o are slower due to simultaneous swap i/o.
    But if your container are using all guar memory and it's not the caches - that isn't right, either your software settings aren't optimal or you need more guar memory.

  • smansman Member
    edited June 2013

    Nobody should be using Burst anymore imho. If still running CentOS 5 OpenVZ they should upgrade to CE6 OpenVZ. CE6 OpenVZ is more stable than 5 in our experience. Also doesn't cause problems with Java anymore. It's all related to the new memory management which ties in with Vswap. We also notice I/O sharing seems to work better in 6. No reason not to upgrade imho.

Sign In or Register to comment.