vSwap + Burst at the same time?

klikli

@Magiobiwan said:
Also, some clients decide to use their burstable RAM 100% of the time (which is sort of not what it's intended for. BURSTABLE RAM!) which can throw off node usage statistics.

No offense, but people are actually supposed to be allowed to use burstable memory up due to how memory is counted in older versions of OVZ. See http://www.lowendbox.com/blog/why-i-dont-like-openvz-vps-plans-with-large-burstable-memory/ and OVZ wiki.

sman

@Samuel said:
sman, with all due respect, insulting me doesn't help. On top, that statement you made is just wrong - I suggest you first read about what Burst is and what vSwap is and then, maybe, try again and don't confuse reality with "your way of thinking". Just saying, you'll fall from your "high horse" if you try to belittle others, not nice.

I'm not on any high horse and don't have anything to prove. My bad if it came out that way. I just tried to explain it a little different because there are common misconceptions. Irrelevant anyways since burst is going away.

If you want to understand the truth and don't want to listen to me then google it.
http://hostingfu.com/article/guaranteed-memory-openvz

http://www.lowendbox.com/blog/why-i-dont-like-openvz-vps-plans-with-large-burstable-memory/

http://www.webhostingtalk.com/showpost.php?p=6933231&postcount=16

jcaleb

I checked, hostigation uses .32 kernel.

jfn

I've just recently signed up after 11 years at WHT, mostly to help in the technical arena. I've administered OpenVZ nodes/containers under UBC with 2.6.18 and VSwap with 2.6.32. In my experience, I've never heard about running both at the same time.

Seems pointless to allow burst memory on a kernel that's whole point is to phase it out.

Any '0' values for swap = no running VSwap on the VE.
Twice as much "Mem:" as the amount offered, when running 'free -m' from the CLI -- assume Burst is active.

It seems that VSwap hasn't been defined as clearly as it should be. Most have seen the OVZ description -

"VSwap $foo $foo simulates swap by artificially $foo $foo slowing down the container $foo while not effecting disk I/O unless the node is truly swapping"

And it feels like for some it's a turn-off.
Many people assume this to mean a huge decrease in performance now that their burst memory is going away.

What OpenVZ hasn't clearly defined is that VSwap containers have quite an advantage over it's tired grandpa, UBC.

An example of this performance enhancement is the memory caching - when VSwap was first making rounds, a lot of folks simply looked at the amount of "free" memory in top, and, some even wonder why their guaranteed 1GB shows only 6285k "free" - not knowing what broke, reboot their machine, and when it doesn't change anything, assume something's taking their memory, or try sync; echo 3 > /proc/sys/vm/drop_caches and get a 'permission denied' error.

Providers went as far as to assume dcache leak? Not sure why. drop_caches actually degrades performance. http://i.imgur.com/dTi98pn.png

I've got a handful of daring clients who are running a JVM without performance issues. That's improved over the last 8-10 months of kernel updates.

FYI, while writing this, I may have been able to fake out UBC parameters - kind of. :-P I just reloaded the OS on my dev container with an old UBC config sample file ( http://i.imgur.com/kasBHGY.png ) on an obviously VSwap environment ( http://i.imgur.com/bjI552b.png ) but it took a wee bit of tweaking through vzctl and damn near every control panel on a VSwap HWN will overwrite the .conf - but I'm running a cPanel install and will check the performance over the weekend. We'll see if it's any different, but as a provider, I wouldn't offer it as an option for clients. Risky.

-John