Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

So, my server is a VPS with a LAMP, Webmin, and an Indefero installation. It runs at 512mb RAM and it's great.

My friend told me of a VPS company that gives 128MB ram for $15 a year (eighty cents a month). That's pretty cheap. Even if I ran 7 seperate VPSes, that would still be cheaper than my current plan.

Is it worth moving my seperate services to a few VPSes rather than keeping them on my single current VPS? I could put Apache on one, MySQL on one, and a Firewall on one.
What differences, good or bad, should I expect to see performance-wise?

So, with quality and price aside: hypothetically, if I was currently using a 5gb ram plan, would it be better to switch to 5 1gb plans?

share|improve this question
Could you give us the website of this company? I'm very curious and sceptical about this offer. –  Kenny Rasschaert Mar 15 '11 at 20:20
you get what you pay for, friend. Don't go there. Cheap, fast, reliable, pick two. There is no possible way for any company to offer this deal in good faith. It's either a bait-and-switch, or you're going to deal with incredibly oversubscribed resources, horrible downtime, and unresponsive support. –  EEAA Mar 15 '11 at 20:31
@kenny.r buyvm.net –  Derek Maciel Mar 15 '11 at 20:54
Reframed to concentrate on the practical aspects and ignore the specific cost implications, this might be a valid question. (though as it currently stands I don't disagree with the closure) –  David Spillett Mar 15 '11 at 21:43
add comment

closed as off topic by Zoredache, Iain, Scott Pack, ThatGraemeGuy, Ward Mar 15 '11 at 21:17

Questions on Server Fault are expected to relate to professional server, networking, or related infrastructure administration within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

1 Answer

up vote 2 down vote accepted

Any really cheap VPS deal is going to be very heavily oversold or the company is operating at a loss. If the arrangement is heavily oversold then you will experience performance issues at times, particularly with regard to I/O but also with CPU allocation. If such a business isn't heavily oversold then it will go out of business shortly unless the service is some sort of loss-leader to grab people's attention in which case support is unlikely to be top notch when they realise they are not going to make more money out of you.

So from that point of view I would avoid this plan without even considering the technical issues.

Running individual services on several VMs on the same host may turn out to be as fast as your current VPS (or at least "fast enough" for small loads, and perhaps faster for large loads if your design scales well over multiple machines) but it would be a lot more work to setup and would have some extra limitations. You could have the seven VMs you mention in an arrangement like this for example:

                                             3             6
                                      ,---> web  -------> db  <----.
                                      |    server   |    slave     |
                                      |             |              |
          1                2          |             \       5      /
       firewall /  ---->  load    ----|              >---> db  <--<
    external access      balancer     |             /    master    \
                                      |             |              |
                                      |      4      |      7       |
                                      `---> web  -------> db  <----'
                                           server        slave

and properly setup you could expand quickly by adding more web servers or DB servers as needed. But there are a lot of issues to content with:

  • You need to configure that load balancer well
  • Each web server would need to be well tuned to work in 128Mbye of RAM or you'll be swapping so that IO hit from excessive contention due to heavy overselling is going to hit hard, and getting an Apache+PHP setup to work well in that little can be impossible anyway at the best of times depending on what you are running (check the potential per-process memory requirements for wordpress, for instance). You might be able to mitigate this by using a different web server (nginx for instance) and/or having the PHP instances running on yet more VMs called via FastCGI over the network, but this is yet more complication to setup efficiently and may still be impossible depending what your scripts do.
  • You are going to have to configure that database replication either using one master with read-only slaves (which will require changes to your apps) as in my diagram or master-master arrangements which can be far less efficient if transactional integrity is something you care about.
  • Each DB server will be limited to 128Mb: this can be a pain for mySQL and will require some tweaking generally, and a big query on one server is not going to be able to "borrow" memory spare on another so that limit is fixed. If you are not very very careful the DB nodes may end up swapping in which case there is that nasty IO contention surprise again.
  • Four 128Mbyte machines will not operate as one 512Mbyte one: for a start the OS and app overheads are pretty much fixed and will apply to each node individually and nodes will not be able to share their RAM pool so a large query on one DB server or large process on one web node will not be able to second RAM allocated to another, currently idle, node. Seven machines 128Mbyte machine are not overly likely to work as well as one 512Mb one for many load patterns.

Further to the "there must be a catch" front, that 128Mbyte of RAM may not be dedicated: it might be "64Mb burstable to 128Mb" for a VZ based host or "64Mb with 64Mb swap" for Xen based systems. Even if theca RAM is nominally dedicated to your VM some virtualisation solutions allow over-committed RAM (VMWare does to a certain extent) so you find parts or your "dedicated RAM" paged out to the hosts swap areas which would be a massive performance hit. Another killer catch is that communication between the VMs (not just between them and the outside world) might count towards your bandwidth allocations: so pulling 512Kbyte from the database to one of the servers and after some computation sending a 128Kbyte response to the client might count as 1664Kbyte in total (512 out of db node, 512 into web node, 128 out of web node, 128 through load balancer, 128 through firewall) not just the 128K, and replication traffic between the DB nodes will count against your quotas in that instance too.

lt;dr: While this may be possible for some workloads (i.e. if each web/app/sql node in your design can run efficiently in that little RAM and you have enough nodes to cope with the same load) it is probably far far far far more hassle than it is worth, for light loads is going to run slower even on a good host (due to extra network overhead) and a really cheap host is unlikely to be a "good" host (an expensive host isn't guaranteed to be a good one, but it is slightly more likely!). Is all the extra setup and maintenance time involved really worth less than the monthly cash you would save?!

Their is one reason I might suggest doing this which is to learn: it could be an interesting project to learn the techniques, and gain first hand experience, of trying to scale apps over multiple machines for performance and/or availability reasons. I wouldn't recommend it for a production setup, even for a personal project, unless you already have that knowledge and experience (which as you are asking the question, I assume you do not).

Still lt; dr: I would stick with you single VM.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.