It seems that keeping up the the apache mpm_prefork and mod_php will not be the solution anymore. Most sites suggested to use mpm_worker instead, because it uses less memory (and my problem was, that my Apache consumed all my memory). On the other hand there could be some problems with thread-safety, but I liked to give it a try. PHP will not me used as an Apache module any more. Instead we will run PHP as a FastCGI script.

A short step by step tutorial for switching from mpm_prefork to mpm_worker with using PHP.

• Open a terminal session as a root user.

  apt-get install apache2-mpm-worker libapache2-mod-fcgid php5-cgi

  apt will complain about a few things and will remove some of the previous installed packages. After installation make sure that mod_fcgid is enabled.

• Edit you /etc/apache2/apache2.conf or /etc/apache2/httpd.conf or any config file that will be parsed by apache and add this:
  1. AddHandler fcgid-script .php
  2. FCGIWrapper /usr/lib/cgi-bin/php5 .php
  3. Options ExecCGI FollowSymlinks Indexes
• Now enter you /etc/apache2/sites-available directory and edit all the the files there. Every file should contain at least one “VirtualHost” node. Within these “VirtualHost” nodes there should be one or two “Directory” nodes. If not already there add a new line starting with “Options” and add “Indexes” and “ExecCGI” as parameters on these lines. It should be look like this one:
  1. Options Indexes FollowSymLinks MultiViews ExecCGI
  2. AllowOverride AuthConfig
  3. Order allow,deny
  4. allow from all
• Restart apache:

  /etc/init.d/apache2 restart

Hopefully now everything should work as before. If you had enabled eAccelerator or any other byte code cache system or if you had mode some modifications on you php.ini you now have to copy them to your “new” php.ini located at /etc/php5/cgi/php.ini

A few things wont work as before, e.g. when use user authentication by PHP and not by htaccess. There are also a few issues I read about, but nothing which affect my sites.

As a result I would say spending this hours messing around with Apache and mod_fcgid was a good investment. My server now need only 90 MB Ram when idle, it was 250 MB Ram before. Even under load memory consumption stays lower as before. I hope this will be the last tweak for I longer time.

Using PHP as a FastCGI script gives you a lot of new options. So if you have a lot of time to spent or very worried about the security of you web server you could use the Apache module suexec which then could execute the script as a special user and not as the default web server user www-data. It could even use multiple user for each virtual host / directory.

Interesting links:

• http://brian.moonspot.net/2008/02/13/apache-worker-and-php/
• http://www.ibm.com/developerworks/linux/library/l-tune-lamp-2.html Tuning Apache and PHP
• http://www.ibm.com/developerworks/library/l-tune-lamp-3.html Tuning MySQL
• http://ivan.gudangbaca.com/installing_apache2_and_php5_using_mod_fcgid More detailed instruction how to install mpm_worker and PHP via mod_fcgid

• 20 GB Raid 5 Storage
• 512 MB RAM, max 2 GB RAM
• 2 TB Traffic

At this time I thought it would be nice to install every thing by myself, so I choose a plain “Ubuntu 8.04 LTS 64 bit minimal” as operating system for my vHost. I installed Apache2, PHP5, MySQL and all the stuff I needed. It all works fine and I was really impressed by the speed of this virtual server.

Then I moved sportinleipzig.de, which I made during the time at my last company to this new server. This page does not have a very high traffic (200 unique visitors a day), but a lot of content (at least 5000 “static” pages). After 2 days the server crashed the first time, whereas crash means, that he is still alive, but does not respond to anything more then a simple ping. I restarted the server over the admin panel. Half a week later the server crashed the next time. Investigating the cause for these crashed I found out a few interesting things.

First a blamed mod_tora which I installed on this virtual server to check if it is ready to use for some production code. Then I deactivated eAccelerator, because I thought it could be possible that it has some memory leaks. I even deactivated Piwik which I use as a tracking system for all the visitors on the pages of this server. (It is very nice! If you need some visitor tracking, give it a try.) But the server still crashed ever few days.

Later I recognized that these crashes possibly occur when Google starts to crawl the page, as the page was not completely indexed anymore. So I started to do some load test on the server. A good page to start is loadimpact.com and the Apache command line tool ab, which both give you the possibility to run a lot of requests on you own server. Having a ssh session open and refreshing the status page of the Virtuozzo panel it became more and more clear. These kind of virtual server are very restricted how many resources they could consume and there a few limit that are easy to reach:

• kmemsize:
  

  The size of unswappable kernel memory allocated for the internal kernel structures for the processes of a particular VPS.

• shmpages:
  

  The total size of shared memory (including IPC, shared anonymous mappings and tmpfs objects) allocated by the processes of a particular VPS, in pages.

• numproc (maximum set to 128!):
  

  The maximal number of processes the VPS may create.

• numfile (maximum set to 8192, this is okay):
  

  The number of files opened by all VPS processes.

• numtcpsock and numothersock (both set to 720, means: no socket servers on virtual servers!):
  

  he number of TCP sockets (PF_INET family, SOCK_STREAM type). This parameter limits the number of TCP connections and, thus, the number of clients the server application can handle in parallel.

  The number of sockets other than TCP ones. Local (UNIX-domain) sockets are used for communications inside the system. UDP sockets are used, for example, for Domain Name Service (DNS) queries. UDP and other sockets may also be used in some very specialized applications (SNMP agents and others).

There are a lot of other limits set to the server, but the first three are these limits that made my server crash, when having tons of requests on the Apache.

I am using the Apache2 in the prefork mode (this is default if you install it via the Ubuntu repositories). This means the Apache spawns a few processes to handle the requests. If load raises more processes will be created, if load goes down unused processes will be destroyed. Forking new processes cost a little bit time so the Apache keeps some processes ready just in the case of load peak. During the time google crawls the page many processes where created to handle the load. The problem was that these processes consumed to much memory (probably this could be a memory leak in one of the PHP  scripts) and some of some became zombies, leading the virtual server to consume all resources and then crash.

The solution:
Edit you “/etc/apache2/apache2.conf”. Search for this section:

You could read in the comment of the config the impact of every parameter. The important one is the last one which is set to “0″ by default, which means that processes live as long as possible. Setting it to “500″, which is quite conservative, makes every process ends after serving 500 request. This also makes sure that all the allocated memory is freed. That causes that processes need to be created more often, so I also raised “MinSpareServers” and “MaxSpareServers”, which are the processes keept ready for load peak.
In conclusion my server spends a little more time on spawning new Apache processes, but this makes sure memory is cleaned more often and finally solved my problem!

P.S.: I don’t know if this is on all virtual servers, but the vHosts at 1und1 have a “/proc/”-entry for reading the limits of you server. You type into the terminal:

root@foo:~# cat /proc/user_beancounters

PHP is not the fastest scripting language, that truly a fact. Except from optimizing the scripts there a few possibilities to speed everything up. One is to install a byte code optimizer and cache on your server. They cache the byte code created by the PHP parser and try to optimise it. So every time some one requests for a page on your server the script does not have to be parsed again. This brings a speedup of 120 – 250% depending on you script. There are several byte code caching program available, the one I like most is eAccelerator. Sadly eAccelerator is not available through the Ubuntu repositories so you have install them yourself. Here is a short description how to archive this!
Everything is done from the terminal as a root user.

• Prepare you system for compiling a PHP extension:

  apt-get install build-essential php5-dev

• Choosing a folder for build process. I used “/usr/local/src/”
• Getting the sources from the eAccelerator site:

  wget http://bart.eaccelerator.net/source/0.9.5.3/eaccelerator-0.9.5.3.zip

• Extract and delete the archive

  unzip eaccelerator-0.9.5.3.zip && rm eaccelerator-0.9.5.3.zip

• Enter the folder

  cd eaccelerator-0.9.5.3

• Prepare as a new PHP extension and compilation

  phpize
  ./configure --enable-eaccelerator=shared

• Compile and install

  make
  make install

  The install process prints out a folder where eAccelerator has been installed. Remember or copy it, you will need this later.

• Enabling eAcceletor: Editing your “php.ini” or create a new ini file in you conf.d directory of PHP. (You can find them here: “/etc/php5/”.) Insert the following:

  zend_extension                  = "/usr/lib/php5/20060613+lfs/eaccelerator.so"
  eaccelerator.shm_size           = "0"
  eaccelerator.cache_dir          = "/var/cache/eaccelerator"
  eaccelerator.enable             = "1"
  eaccelerator.optimizer          = "1"
  eaccelerator.check_mtime        = "1"
  eaccelerator.debug              = "0"
  eaccelerator.filter             = ""
  eaccelerator.shm_max            = "0"
  eaccelerator.shm_ttl            = "0"
  eaccelerator.shm_prune_period   = "0"
  eaccelerator.shm_only           = "0"
  eaccelerator.compress           = "1"
  eaccelerator.compress_level     = "7"
  eaccelerator.allowed_admin_path = "/var/www/eaccelerator"

  In the first line enter the path printed out during the install. In the last line you could enter a directory for the eAccelerator admin tool, if you want to use it.

• Create the cache directory:

  mkdir /var/cache/eaccelerator
  chown www-data.www-data /var/cache/eaccelerator

• Restart you Apache!

  /etc/init.d/apache2 restart

There are a lot of setting in the ini file. The whole list and the description of them could be found here:  Ini-settings.

To check if everything is working open up a page on the server that contains the “php_info();” command. There should be some thing like this:

eAccelerator

Enjoy the speed!