From Athenaeum
Jump to: navigation, search

  • Cool index framework: h5ai
  • Really Strong Cipher Suit

Check connection states with the following command:

netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

See how keep alive relates to apache processes here.

Apache Processes

Bellow is the equation to determine the proper value of maxclients.

(Total RAM - OS Reserve RAM) / (Average Apache Process % Consumption * Total RAM)


(2048 MB - 1024 MB) / (1.83% * 2048 MB)
1024 MB / (0.0183 * 2048 MB)
1024 MB / 37.4784

You have probably made the error of configuring Apache to use far more than all of your ram. This is an easy mistake to make.

I am assuming you are using a Prefork Apache, and an in-process application server (such as PHP or mod_perl). In this model, you will end up with a maximum of (MaxClients * max memory usage of your application per process) memory used. If you don't have nearly that much, it's time to decrease one, the other or both.

In the general case, this means decreasing MaxClients to the point where your server has enough ram to cope.

The default values typically used for MaxClients (150 is typical) are not suitable for running an in-process heavyweight application server on a modest machine if you are using the Prefork model (Most application servers either don't support, or discourage, the use of threaded models).

However, decreasing MaxClients will eventually cause the application to become unavailable, particularly if you have keepalives on and the keepalive timeout too long. Processes which are just keeping a connection alive (state K in server-status) still use a lot of RAM, and that may be a problem - try to minimise keepalive timeout, or turn it off altogether.

You need to keep an eye on server-status (as provided by mod_status).

Of course you should only make ANY of these changes if you understand the consequences. Think twice, change the config once. If you have ANY ability to test the changes with simulated load on a similar spec non-production machine, do so.


  • Guidelines for relatively flat web directory permissions. Permissions for frameworks will be different.
  1. the files to be served must be readable by user 'apache'
  2. the directories must be searchable by user 'apache'
  3. CGI programs must be runnable by user 'apache'
  4. user 'apache' should not own any files
  5. user 'apache' should not be permitted to write any files
  6. group 'apache' should not be permitted to own or write to any files

It makes more sense in most setups that whoever has to modify the files (via ftp/etc) should either (a) own them, or (b) be in a group that has write permissions for the files.

Chrooting Virtual Hosts and Overriding Apache2 Permissions

Mod ruid2 - allows you to change executing user permissions on apache2 per virtual hosts so that you can completely jail sites to their respective directories.