VPS Burst RAM

[optrex]

I'm getting conficting information over burst RAM allocation, with a new VPS package I am testing. I'm still not convinced that my allocation is correct.


Support tells me that "You can not see burstable-ram on the VPS." and point me towards the "what is burstable RAM URL"


But since you are using slmmemorylimit in virtuozzo the hard limit should surely reflect the "burst" allocation, whilst the soft limit should reflect the guaranteed allocation.

Currently both my soft and hard limits are set to 384MB

Also if I look at the memory allocation in WHM I get

Mem: Total 393216 Used 193292 Free 199924

On my other 3 VPS with 2 different providers the Total ALWAYS reflects the burst allocation.

Could someone please clarify the situation?

[optrex]

anyone able to help?

[Administrator]

it seems that your new VPS is setup on node which uses SLM virtualization. You don't have Burstable RAM on SLM.

UBS virtualization has got some problems as it has started creating problems for other VPSs on hardware node and thats the reason our new nodes have been configured with SLM virtualization. I will request our developers to remove burstable RAM feature from our website as we won't offer burstable RAM from now onwards.

[optrex]

I think if you did that it would be a bad marketing move to remove burst RAM. This is what everyone else is doing:

Ok so we are changing the way memory is handled within vps’s as things have changed a bit since we set them up.

We are switching to “SLM” memory management so that our VPS’s act more like a real server. Before they operated on the “UBC” system which had a number of barriers and quite often needed modification for different customers.

So from now on if we wish to setup a VPS with 256MB of RAM, bursting to 512MB we would run this command on the hardware node:

# vzctl set 101 –slmmemorylimit 256M:512M
(limits average memory usage to 256 megabytes, allows using up to 512M).

where 101 is the unique ID for the VPS

If you don't allow bursting then its going to create all sorts of problems when people want to run an install, as services will shutdown if a VPS is running close to its "average" limit.

As a customer, I would like to see

slmmemorylimit 384M:1024M applied to my VPS to comply with what I have paid for.

[jon123]

Originally Posted by optrex

If you don't allow bursting then its going to create all sorts of problems when people want to run an install, as services will shutdown if a VPS is running close to its "average" limit.

Is this the cause of my problems where running updates on something like RV just freezes everytime? Where the only way around is to run from shell (takes ages), or ask support (who are understandably reluctant as it is third party software)

[Administrator]

I need to talk to our senior members from VPS team to figure out what they have decided in terms of burstable RAM. SLM won't make any sense if we allow high amount of burtstable RAM as our main target is to keep VPS restricted to their allocated resources.

I will let you know once we are done with our discussion on this topic.

[James]

Hello Grant,

Our Senior VPS admin has updated your ticket.

Please refer the original ticket for complete information regarding the Burstable RAM and SLM memory.

[optrex]

Yes I've got the ticket reply. It explains about the how burstable RAM works, how SLM works and what Vitruozzo SLM is currently doing, however it does not answer my question.

My SLM is set at 384M soft and 384 hard. This means it limits average memory usage to 384 megabytes and allows using up to 384M. - so where is my burst allocation?

Its clear enough on SWSOFTs own forum at http://forum.swsoft.com/showthread.php?t=31351

I bought into a package sold as having 1Gb burst and I do not currently have that option on my plan. I know what burst is, I know how it should be used, I know that it should not be relied upon as always being available. I know that you don't want to over subscribe your hardware, but at the end of the day someones dropped a clanger.

You are probably now in the position where you have a number of VPS on a given node with not enough physical memory to correctly allocate using SLM.

So how do you correct this? Your current offer of

• moving to the next plan up at a higher charge

or

• moving to an old node where you do not use the SLM and can give me burst

is not acceptable.

It should be noted that I have specified my VPS at 384 to correctly run my site on a day to day basis. I am not intending to run my site using 1024 burst 24/7. The point is, it was advertised and I have piad out for it on that understanding. It is also a functional requirement as stated above when doing installs etc.

[Administrator]

Please provide me with the ticket number. I will request one of our VPS Team members to include burstable RAM for your VPS.

[jon123]

Originally Posted by Administrator

Please provide me with the ticket number. I will request one of our VPS Team members to include burstable RAM for your VPS.

NO no no no no! Please make sure I have the same! And all others who have subscribed to the same option.
This is not negotiatiable. If this it what you state in your plans then this is what we should have!

I admit i have no idea what (if any) the affect will have upon me, but I am sick and tired of being offered a service, albeit isp, bb, webhosting, etc, who fail to deliver on their promises. If you say you give certain criteria for a certain price then you should deliver!

If WHUK wants to be set apart from all the rest then it's easy, deliver what you preach! And in this context if burstable ram is what is offered, then burstable ram should be available!

[optrex]

Originally Posted by Administrator

Please provide me with the ticket number. I will request one of our VPS Team members to include burstable RAM for your VPS.

Many thanks, my ticket number is #IKT-34958-801

[Administrator]

Originally Posted by jon123

NO no no no no! Please make sure I have the same! And all others who have subscribed to the same option.
This is not negotiatiable. If this it what you state in your plans then this is what we should have!

I admit i have no idea what (if any) the affect will have upon me, but I am sick and tired of being offered a service, albeit isp, bb, webhosting, etc, who fail to deliver on their promises. If you say you give certain criteria for a certain price then you should deliver!

If WHUK wants to be set apart from all the rest then it's easy, deliver what you preach! And in this context if burstable ram is what is offered, then burstable ram should be available!

who said there's no burtsable RAM on your VPS ?

your VPS is hosted on one of our old nodes and that is still running with UBS. We've not yet converted our old nodes to SLM.

[jon123]

Sorry i misread (or more accurately read too much into) your earlier post and assumed all your vps hosting did not have burstable ram.
I thought this may have been my problem with running updates from whm.

[Administrator]

Originally Posted by jon123

Sorry i misread (or more accurately read too much into) your earlier post and assumed all your vps hosting did not have burstable ram.
I thought this may have been my problem with running updates from whm.

RVskin Admin section gives similar problem on Dedicated Servers as well. I've had similar problems while updating RVSkin from WHM. We have set crons to update RVSkin and Fantastico on our Shared Servers as the update from WHM fails to work sometimes for unknown reasons.

[optrex]

Just to finalise this thread as I am aware people are following the progress.

My physical memory was increased to 512 soft and 512 hard, presumably to be brought inline with the new VPS starter package now being offered (without burstable RAM). The trade off however is that there is no longer any burst.

I am going to wait and see how things go with activity of my VPS before I decide whether 512:512 behaves better than the 384:1024 expected when I initially purchased.

Although I anticipate it will help daily running of the VPS as more physical memory is now guaranteed, I'm expecting processes to be killed off during peak install/upgrade times, due to the lack of burst, however only time will tell on this one.

I must thank the team at WHUK for taking the time to listen to my points and putting in a resolution. They have also now made the marketing of the new SLM packages a lot clearer.