This blog and some other pages run on 100mb RAM + 100mb SWAP. Because some people are interested in my configuration I will show you. First its not correctly to call it LAMP but better LNMP because I interchanged apache with nginx. Then I want to note that I'm no expert and there might be room for improvement - see it as a first idea to get your server up.
My server is a vserver and costs only 1.5€ per month.. That's the only reason why one want so low memory I guess :).
Since it is only a vserver I can't configure the swap-size :( also I have no other optimizations for the base-system. I think the ram of the kernel isn't accounted for the vserver and also I didn't want to use support if I made some wrong kernel-optimizations. Besides that, I used top to monitor all processes and shutdown everything which I don't need (ftp,mailserver..) - also make sure to update your runlevels so a restart won't require to shutdown everything again.
Apache isn't designed to be memory efficient - on the other hand nginx is designed to be fast and performant. The switch must be well planed, because most applications require some .htaccess modifications - luckily I just needed to port yii where already some example nginx.conf things are stored inside.
Beside that I think nginx is superior to apache in terms of simple configuration.. I spent hours to set up subdomains on apache while it were just minutes inside nginx. Besides that, not much configuration needed to be done, since the memory footprint of a default nginx is already quite low. So my config file for version 1.2.4 [gist]https://gist.github.com/4065226[/gist] Note that this is probably not perfectly configured and some optimization could be done (I think I won't need so much worker and some stuff looks redundant)
ps aux |grep nginx reports RSS of 2060 -> so 2mb
I think here are quite many possibilities to save Memory - but also with each memory saving you might lose query-speed. The My.conf looks like this (version 5.0.51): [gist]https://gist.github.com/4065295[/gist] Again I'm not an expert for this configuration but maybe it helps one. For example the "skip-*" can save some memory for unused parts.
ps aux|grep mysql reports RSS of 156524 -> so 156mb After a restart it is btw only 30mb.
As you see in nginx.conf PHP must run as fastcgi: I think there basically exist two possible solutions for this: One is the spawn-fcgi script from the lightppd package which gets started by:
/usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u www-data -g www-data -f /usr/bin/php5-cgi -P /var/run/fastcgi-php.pid&
Unluckily since my last update it crashes randomly - which brought me to another solution: this (see at the bottom) blog post inspired me to try php-fpm. Until now I don't regret the change. The initialization was a bit strange - one has to edit /etc/php5/fpm/pool.d/www.conf add a "listen 127.0.0.1:9000" and start it with "/etc/init.d/php5-fpm start" - but this was just a RTFM problem of myself \^\^.
In PHP itself I've also did very few configuration - also it is one of my biggest processes:
ps aux|grep php reports three times an RSS of \~25000 -> so 75mb
(I'm a noob with ps and don't now how much memory is shared between those processes.)
There are some other people like me who have few RAM available and blogged about it too. But it looks like there are not much similar whole LAMP-posts like mine..
- Nice overall LAMP solution from an amateur like me :) - also great comments
- Mysql/Apache Configuration
- Mysql Optimization also good comments
As you can see basically PHP and mysql require much memory (1mb of nginx isn't anything where tuning would help). For the mysql-part.. Besides further tuning of the config, I would like to experiment with sqlite - since I use only yii and wordpress, I think a conversion shouldn't be so hard. For php: It doesn't look like anyone looked at it or I'm just having problems with searching :s
Everything adds up to a bit over 200mb - I think some of the reported memory gets shared.. Or the RSS metric of ps isn't exact. The performance is quite good - I think when it blocks for some seconds it is due to a file-io from another vserver instance - but most of the time everything works fluently.