VDS Tuning Guide

This guide is based on conversations we've had with customers on IRC -- it will expand as we have more conversations -- if there's something you want tuned and there's no reference to it here, stop by in our IRC support channel #contextshift on OFTC.net and we'll see what we can do.

Not much of this guide is specific to VDSes, feel free to use the advice elsewhere :)

The Kernel

Having the kernel set up properly can make the whole system faster~

Things which are set in /proc can be saved permanently by putting them into the file /etc/sysctl.conf

Memory Overcommit

Overcommitting memory means telling all processes that they can have as much memory as they want, and then killing semi-random processes when it actually gets used -- this actually makes things run a lot better in some common cases, like on the desktop. On the server, it's better to have things fail logically and safely than to keep them running five more minutes before killing the entire system.

/proc/sys/vm/overcommit_memory is the virtual file which controls linux's overcommit behaviour -- by default it is zero (tell all apps they can have as much memory as they want), for servers it can be better set to two (if there's no memory free, tell the app that there is no memory free)

Be warned, however, that when you change this setting, the kernel will require sufficient swap space to satisfy all memory allocations. Compared to the default setting, this may greatly increase the minimum required amount of swap space. When you change the setting with insufficient swap space available, the kernel will randomly kill processes until memory usage is brought down to the available swap space. So make sure you have enough swap space!

Swap Space

Pushing idle memory onto disk, freeing up the RAM for the file cache, kernel (network) buffers, and active program memory, is a good thing. Have a lot of swap. There is nothing wrong with having swap that is many times the size of your RAM.

To create a new swap file named /swap2 of 256 megabytes and activate it execute the following commands: 

  dd if=/dev/zero of=/swap2 bs=1M count=256
  mkswap /swap2
  swapon /swap2
To have it automatically activated on future reboots, edit /etc/fstab and add the following line: 
  /swap2 none swap defaults 0 0
Change the size and filename as needed.

Pushing active memory onto disk, aka thrashing, is generally a bad thing. Make sure you have enough RAM to hold all your active data, or, conversely, make sure your active data is less than your available RAM (which means tuning memory usage of your applications).

When you got it just right, you should see a mild amount of swap activity. When swap activity is almost always 0, you probably have more than enough RAM... (There are various tools to see disk I/O activity, e.g. vmstat, iostat.)

Disk Speed

Virtual disks have typically more variable and higher latencies than physical disks. This is partially offset by the fact that all our disks are server grade models featuring <1 ms (as opposed to the typical 2 ms) track-to-track seek time, which are run in dual disk RAID1 configuration. The result of all this is that they handle roughly four times the amount of reads, and twice the amount of writes, compared to normal SATA disks.

What this means in practice is that although you can do quite a lot of disk I/O from your VDS, you will find that the time it takes for each individual I/O to be serviced can be quite high.

Thus, generating disk I/O in general isn't a problem, but doing a lot of synchronous I/O is generally a bad idea. This includes such things as virtual memory trashing, which happens when the active set of memory used by all programs is larger than the available RAM, and writing multiple log entries to a database (which likes to do synchronous disk writes...) for each and every web access.

Network Buffers

Need to say something about this, as the current kernel defaults, while perhaps sensible on the average PC, may be lethal on a RAM-constrained VDS...

Web Servers

LigHTTPD is slightly faster and smaller than a stripped down Apache. LigHTTPD + FastCGI is an order of magnitude faster and smaller than Apache + mod_php + mod_perl + mod_python.

Apache

MaxClients controls the number of simultaneous requests to handle -- if each request uses 30MB of RAM (ie, a large CMS like Moodle running in mod_php), and your VDS has 128MB RAM, then trying to run the default of 500 requests at once will quickly grind things to a halt. Setting it lower (5 to 10) will deal with each request faster, and any further requests will be queued; the net result being a much more responsive website.

LigHTTPD

FastCGI is faster than regular CGI; use it where possible. FastCGI processes can be limited in the same way as Apache's MaxClients above.

PHP

For large apps such as Moodle, Joomla, or PHPBB, 90% of the processing time and memory is used in parsing the PHP code. An opcode cache such as APC can make things an order of magniute faster.

Database Servers

MySQL is fast if your data is small and your queries are simple; It crashes, burns, grinds to a halt, and corrupts data when put under load. PostgreSQL is slightly slower for light work, but will keep on going when things get heavy.

Making sure your data is properly indexed can be the difference between a query taking a fraction of a second and taking several minutes.

MySQL

The slow query log will tell you which queries are running slowly, and thus, is very useful in performance tuning. To enable it, open /etc/mysql/my.cnf and set some settings: 

 long_query_time = 20
 log_slow_queries = /var/log/mysql/mysql-slow.log
 #log-queries-not-using-indexes  # if you think that all your queries should be indexed

PostgreSQL

TODO: Memory use tuning

Mail Servers

I don't know much about these. Help?

Spam Filtering

I've heard greylisting is light on CPU and memory, and will halve the amount of spam that the heavy-duty filters have to sort through? Confirm / deny?

spamc + spamd is much, much faster than invoking a new spamassassin process for every bit of incoming mail.