Memory consumption

Posted on July 28, 2011 by Castlegem

(this post will also appear in our dedicated servers blog)

Nowadays, CPU performance is something that is pretty easy to achieve with comparably little investment. Intel’s L/X34xx, E/L/X56xx, or the latest E3 12xx(L) CPUs as well as AMD’s new Opteron 41xx series will cover most requirements one could come up with for a startup site, even with a considerable number of users online at the same time.

A fact, however, that is often neglected, is memory consumption. Memory is key and crucial to your website performing well and supporting a large number of users online at the same time.

Let us consider a typical LAMP environment, i.e. you are running Linux, Apache, MySQL, and PHP. The operating system will not need much overhead, typically a couple hundred MB should be enough, MySQL will need what you give to it (large buffers, high number of connections, etc. increase memory usage, naturally), and PHP is a double-edged sword in many cases anyway. One of the largest memory hog in moderately busy machines is the webserver itself – most often Apache. Even if carefully tuned, and going to extreme setups with either prefork or worker, you can end up anywhere between 5 to 15 MB per connection. Depending on the number and sort of modules you need, this will vary a lot – lightweight servers will be closer to the lower end, but an Apache having everything enabled is more likely to end up with 15MB of RAM per connection – there are alternatives to Apache, and most control panels using Apache will go for the prefork MPM, and unless you want to recompile and configure on your own, this is basically what you have to live with.

Let’s assume 10MB per connection, an average value. Imagine you want to be able to serve 500 simultaneous connections – with 10MB per connection, you are going to need 5GB of RAM for the webserver alone! If a lot of these connections are database intensive, then you might be coming close to 8GB of RAM usage already: so in order to have some safety margin, you should be going for 12GB or 16GB of RAM in your dedicated server (depending on CPU architecture and memory channels) or virtual private server.

Even on a site that is not really busy, with maybe 50 connections at the same time, you should be aware of overall memory consumption: 50 x 10MB, plus OS overhead, MySQL, and PHP will most likely add up to 2GB of memory as well, so here you should be going for 4GB already to have some growth potential.

What happens if the machine runs out of connections and/or memory, and eventually also out of swap space?

your site will respond more slowly;
your site may stop processing requests altogether;
your site may throw errors;
your site might become inconsistent: nothing is worse than an partially processed request that gets through to the database backend at random only;
your site may become unreachable;

A dedicated server will be able to handle such problems somewhat better than a virtual private server – due to its architecture and swap space available. The latter often does not have any swap space (there are virtualisation architectures where this is not true, however, such as KVM, for example) and will be hit full swing instead of being able to mitigate the crisis arising from low memory.

You want to avoid such scenarios – for the sake of your business and your customers. Do not save on memory – better have some spare than have none left.

Linux flavours

Posted on July 27, 2011 by Castlegem

(this post will appear in our dedicated servers blog as well)

Abstract/Summary – basics only

These days, the most prominent Linux flavours are Red Hat, CentOS, Debian, Fedora, SUSE/SLES, and Ubuntu. The number of variants of these flavours is legion, the main distinction here, however, is that Red Hat is a fully commercial branch, whereas the others are available free of charge.

Red Hat is closely related to CentOS and Fedora, and while avoiding too technical an explanation, in layman terms CentOS can be seen as the “free” version of Red Hat, Fedora as the “next generation Red Hat”. There are a lot of caveats with these metaphors, but they help to get an overall idea. Debian and Ubuntu are independent (similar to some extent) flavours with their own community. Ubuntu has gained a lot of popularity recently due to its cloud abilities. SUSE was originally independent and started off in Germany, but has been bought by Novell and has seen a decline in community lately.

Red Hat and CentOS are more conservative in their application of packages and in their approach of going for the latest in everything. This is not necessarily a bad appoach at all – a huge number of commercial, high performance, and mission critical applications are specifically tuned for Red Hat, based on our own Linux experience since 1992, starting with Slackware, we identified Red Hat and CentOS as the leading Linux flavours for our own server environment (this is not a strictly objective judgement per se, as we of course need to evaluate our own needs first, and we encourage digressing opinions).

Red Hat and CentOS are ideal solutions for virtualisation, too. Both offer similar technologies, though we tend to go for KVM with Red Hat, and openVZ with CentOS (openvz will also run on Fedora, by the way). KVM (kernel based virtual machine) employs a different concept than openVZ, and allows running guests in a way such that the guest does not really know it is a guest only. That gives you a chance to, say, run a Windows server as a guest system on a Red Hat (or, rather, KVM) host – openVZ will only support Linux guests, and the ones we have best experience with are CentOS, Debian, Fedora, Ubuntu, and to some extent SUSE.

When it comes to control panels, we have excellent experience with CentOS + cPanel/Plesk, and Debian + Plesk. These setups pretty much work out of the box, and wont give you any hassles in a live environment.

Oversubscription or not? Contention – the good and the bad

Posted on July 26, 2011 by Castlegem

(this post will also appear in the dedicated servers blog. The post here has some content which is pertinent to VPS only)

The terms oversubscription and contention are often heard when it comes to providing services as an ISP, for example regarding CPU resources, memory, bandwidth, etc. Generally speaking, it means selling/providing services or advertising them to more people than there are effective simultaneous resources available. Let us look at bandwidth, an often cited example, first:

Let us assume your VPS is on a Gig link to the host, and that there are 3 more guest systems on the same physical host, also with their own Gig link to the host, but the host only having a single GigE connection to its switch. In that case, we have a contention ratio of 4:1 since we have 4 VPS with Gig links, but only one effective Gig uplink to the outside world available. Here, oversubscription is rarely an issue – a typical VPS going at a sustained gbps isn’t feasible and would be better sold as a dedicated machine anyway, so such rates are only seen during spikes, with the other VPS rarely competing for the available host bandwidth. This example continues from the host to the switch it is connected to – how many other physical interfaces there are that are competing with the respective uplink. A trivial contention ratio here might be 8:1, 16:1, 24:1, or similar – i.e. your typical GigE switch with a gbps fibre uplink has to serve 8, 16, or 24 machines that, in theory, could also use the entire bandwidth of 1 gbps available. Here it is already trickier to judge whether contention might be an issue – a customer with rather evenly shaped traffic curves is more predictable than a customer seeing a lot of spikes during the day, spikes that can take valuable bandwidth away from other customers.

How do ISPs do it? Most ISPs accept contention ratios based on the traffic they see on the switches, routers, throughout the entire backbone. This is a legit practice, and as long as it doesn’t handicap one group of users against another, no one will probably see that is in effect being done at all. Some ISPs sell bandwidth at dumping prices, fully aware that their traffic/cost/revenue model is anything from risky to shady – when you encounter a bandwidth deal that sounds too good to be true, it probably is – like anything in life. Traffic cost patterns have evolved in various regions of the globe, and comparing several providers on a single continent or within a large geographic region (US, UK, continental Europe, etc.) can help you a lot to find out the truth behind the myths of “unlimited traffic” – it also helps asking questions such as “unlimited traffic – I have a website generating 100TB of traffic each month – still unlimited?”. Often the smallprint of providers will tell you things like “irregular use is due to caps”, “bandwidth in excess of…is subject to approval/surcharge”, etc. Make sure you get your ISP to give you the facts straight, ask until you are sure that what you need and want is going to be provided without hidden costs.

How do we do it? In terms of bandwidth, we have a contention ratio of 1:1. Yes, that’s correct. Bandwidth we sell is dedicated, and we make sure that you won’t share it with any other customer even in case all of them are requesting their share at the very same moment. This model has its disadvantage: our traffic is more expensive than oversubscribed traffic. The advantage: you get what you pay for, no matter what, no hidden costs, no caps.

What then, about memory. Often, for virtual private server setups, you will read guaranteed vs. burstable RAM. This clearly speaks of contention already. Frankly speaking, it means that you can use excess resources only when there are any left and not being required by other customer on the same host system. You have to be very careful here, imagine the following:

You run a website in a LAMP environment that, on average, uses around 2GB of RAM. Twice a day, however, you are doing updates, ads, anything, and the machine then requires 3.5GB of RAM for an hour each – your VPS contract states 3GB of RAM guaranteed, burstable to 4GB (often only displaying the burstable RAM in the system itself). Now if during your high traffic time you request the additional 1.5GB of RAM, you are only guaranteed 1GB – you will only get the remaining 512MB if and only if no one else is needing them and the host has free resources available. If you do not get them, your customers will see the site being down, broken, or throwing errors. Again, make sure to ask the right questions from your ISP: ask about contention ratio, reserves, general customer profile you share the host with, and ask a lot of what if’s.

How do we do it? We guarantee RAM, for us, guaranteed RAM is burstable RAM as well. No difference. Again, this means our prices are slightly higher than your run of the mill VPS. But the advantage is that you can lean back and relax without having to worry about memory or lack of resources. For us, it is simply not feasible to put your business at risk – we want you to succeed, therefore we want you to have all resources available you pay for, at any time, without any smallprint.

Control panel or not?

Posted on July 26, 2011 by Castlegem

(a similar post will appear in our dedicated servers blog, with some adaptions, though)

When you finally have your VPS up and running, you will have to decide whether you want it “bare” or with a control panel on top of it.

The advantages of a control panel are obvious:

easy administration of trivial tasks, such as adding domains, accounts, email addresses, etc.;
graphical interface instead of having to go through a console or plain windows administration tools;
easy update mechanisms;

The disadvantages, however:

generates memory and CPU overhead;
once you go for a control panel, you are stuck with it;
difficult to next to impossible to make changes to the underlying operating system without potentially critical repercussions on the entire system;
features offered by the operating system and needed by you might not work with the control panel;

Control panels are not extremely expensive (besides, you can always go for one of the free ones) – for virtualised environments prices vary around USD 10-30 per month.

So what, then, are the decisive factors whether to go for a control panel or not? We believe that even for experienced administrators, a control panel makes sense if you want to offer webhosting or want to act as a reseller, if you have a large number of standardised services or packages (domains, hosting & email accounts, a run of the mill LAMP environment, etc.).

A control panel might not be the best solution if you only run a single application or site, especially if there is no hosting associated with it, for example running an eCommerce site such as a webshop on one server and keeping your emails on a separate hosting account wouldn’t require you to have your own control panel – if you are familiar with system administration, you can find your way around your application and server anyway, and if you are not, the person or company hired to maintain your system for you isn’t going to benefit from the control panel either, quite the opposite: it might even make their task more complex and difficult because they will have to make sure that the underlying operating system and the control panel are always in sync – unnecessary overhead in every aspect.

Virtual Private Server – VPS – the basics

Posted on July 25, 2011 by Castlegem

A virtual private server, or VPS, can be described as a mostly (we will get to the meaning of that further below) separated container inside a physical machine pretending it is a machine of its own.

As opposed to a dedicated server, where you own all resources of that particular machine, in a VPS you are being allocated only a subset of resources, typically configurable by parameters such as:

memory;
disk space
CPU cores/speed;
bandwidth;

The advantage of a VPS is its compactness – you can pretty much do whatever you could also do with a dedicated physical machine, but nevertheless enjoy the much lower cost of a VPS compared to paying for an entire server. The disadvantages of virtual private servers lie in their contention ratio and scalability.

The more customers hosted on a single physical machine (even powerful machines), and unless we are talking about workhorses such as IBM’s P7 series, which can be virtualised nearly without contention), and even with no oversubscription, you will face increasing rivalry for a machine’s resources between the guest systems, such as I/O, memory, or CPU power. Scalability is another issue – you cannot scale a VPS up without ends. The current hardware of everyday’s high performing Intel or AMD architecture cannot be scaled ad infinitum, and a site requiring resources that were usually only served by dedicated servers a few years ago might even benefit from the additional performance (albeit at higher cost) from a dedicated machine with the same general specs such as CPU, memory, and disk space.

In this blog we will focus on virtual private servers in general, how they compare to dedicated servers, where to draw the line, typical administrative caveats, and just everything that comes to our mind which might be helpful for you in running your VPS. We hope that this blog will prove useful to you!