Got your dirt cheap VPS with only 64MB guaranteed memory on OpenVZ? Want to move your WordPress blog from some insanely oversold shared hosting to your shining low end box? If you follow the “traditional way” of setting up a Linux web server — installing Apache, MySQL and Mod_PHP — you will soon find that your site dying a horrible death, with pre-forked Apache processes killing themselves left and right. Or your entire Xen box descending into swapping hell before completely locking itself up.
So is it possible to host a low traffic PHP site on a low end VPS? Yes, but the first thing you need to do is getting rid of the A in LAMP.
While infinitely configurable, pre-forked Apache (which is required for mod_php) is not really scalable to suit low memory requirement. I won’t get into all the details, but there are several free/open source alternatives.
At LowEndBox, I am running Lighttpd + PHP in FastCGI mode. I am running 2x slave FastCGI process and it works quite well for 3x very low usage sites on this box, using less than 15MB of memory all together.
# ps -u www-data u USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND www-data 27509 0.0 3.1 6672 2092 ? S 11:50 0:00 /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf www-data 27510 0.0 7.3 16656 4848 ? S 11:50 0:00 /usr/bin/php5-cgi www-data 27512 1.1 11.9 16652 7868 ? S 11:50 0:04 /usr/bin/php5-cgi
Installing them is easy —
# apt-get install lighttpd php5-cgi
Then just install other PHP modules (MySQL, GD, etc). Here is a comprehensive guide on running PHP on Lighttpd, but on Debian/Ubuntu, you usually just need do:
# ln -s /etc/lighttpd/conf-available/10-fastcgi.conf /etc/lighttpd/conf-enabled
Make sure you edit the 10-fastcgi.conf and (1) leave max-procs at 2 (2) reduce PHP_FCGI_CHILDREN to 1. After starting the daemon, you’ll see 2x php5-cgi process running. With PHP 5.2.x it would not spawn a manager process. However, if you intend to use PHP op-code cache/accelerator, then it would be a good idea to change max-procs to 1 and PHP_FCGI_CHILDREN to 2 so that your 2 worker processes can share the cache (but you’ll see a 3rd php5-cgi process running as manager/dispatcher).
While it’s lighter and faster, Lighttpd does not offer as much functionality as Apache, nor as configurable. For applications that depend on Apache’s mod_rewrite capability, there is usually hacks and work-around for Lighttpd. For WordPress to get clean URL, just add
server.error-handler-404 = "/index.php"
to your configuration file for your WP sites.
Another alternative web server that I’ve used for my other projects is Nginx. It uses slightly more memory (at least 7MB on 32bit Ubuntu) and does not support spawning CGI processes (so all FastCGI procs have to be external). A great piece software if you have very hight traffic site.
Related Posts:
- 5 Reasons Why You Want a Low End Box - May 26, 2021
- Dead Pool January 2012 - February 2, 2012
- exit(0); - January 19, 2012
Nginx, I think, is much better and on my VPS consumes less memory than lighttpd. Also, with lighttpd there will be memory leaks.
Another good idea is to custom compile PHP and get rid as much extra stuff as possible. Also, don’t forget to install APC.
Some more tips at my blog (which btw is Drupal hosted on a 64MB RAM Xen VPS :)
http://dojimun.com/node/5671
@Duke — yes I agree that Nginx in many ways are superior than Lighttpd. It has a much consistent memory usage, whereas I found lighttpd can leak like crazy in highly loaded proxy/fastcgi set up. However in my particular case (Debian 4, Lighttpd 1.4.13, PHP via FastCGI), the memory foot print has been fairly stable at around 2.5MB RSS.
One advantage for Lighttpd is CGI support. So for some obscure scripts that only get run once in a blue moon, they don’t take up memory as fcgi processes when they aren’t used.
In my experience, Lighty’s CGI support is not so great. I have used it to run a gitweb-ish cgi that is written in C, and it causes an extra megabyte of memory consumption every time a link in the cgi is clicked. This same cgi program (gitc), does not seem to exhibit this behavior on other CGI systems. I do not have this issue with perl CGI though in lighty.
However, I have to totally agree with you on the stability of lighty’s memory footprint for non-CGI operations…. except mine stays a little lower at 1.7MB(gutsy), and 1.9MB(etch) RSS :-P
php-cgi processes are another story though, their RSS seems to vary widly, even within the ones that are currently alive. All the way from 1.8 to 4.5MB on my etch server.
nginx/cherokee/lighttpd/apache I think the most important thing you can do is optimise, obviously some can never be as small as other but all can be reduced from their default. I like this guide thumbs up
I chickened out, went from 128MB to 256MB (64-bit Xen, not OpenVZ) and reduced the number of processes Apache will start:
http://blog.lolyco.com/sean/2009/10/25/minimum-xen-vps-for-lamp-oscommercewordpress-at-xensmart/
It’s bloated, but apart from the Apache conf, stock, off-the-shelf Ubuntu.
Love the site, this article has really reduced the memory footprint on my VPS. Thanks.
Have anyone experienced with Cherokee; is php5.3 supported?
Look at their benchmarks: http://www.cherokee-project.com/benchmarks.html
Great, right?
I dont know if there is any problem with using Cherokee and mysql.
The webserver doesn0t have nothing to do with your database.
And http://www.google.com.mx/search?q=cherokee+php+5.3 Some tutorials around
Thanks, Yomero,
I also found an helpful article at http://www.how2centos.com/installing-lcmp-stack-on-centos-5-5/,
Hope someones else working with LCMP give feedback.