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 #contextshift and we'll see what we can do.
Not much of this guide is specific to VDSes, feel free to use the advice elsewhere :)
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
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!
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 /swap2To have it automatically activated on future reboots, edit /etc/fstab and add the following line:
/swap2 none swap defaults 0 0Change 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.)
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.
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.
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.
FastCGI is faster than regular CGI; use it where possible. FastCGI processes can be limited in the same way as Apache's MaxClients above.
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.
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.
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
TODO: Memory use tuning
I don't know much about these. Help?
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.