Apache Tips
From LinodeWiki
Contents |
[edit] Re-generate Apache SSL Key
Like so many others, when I set up my SSL CSR I added a password as the instructions indicated. Problem is, everytime the linode restarts or I need to restart apache it pauses waiting for the passkey to be entered.
If you want Apache to restart without the passphrase required you can adjust the original key file so that it doesn't have a passphrase. Use at your own risk, but the following worked on my CentOs setup.
If you do NOT want to be asked for a passphrase when restarting apache, re-generate your RSA key file.
[root@yourserver /etc/httpd/conf/ssl.crt]# cd ../ssl.key [root@yourserver /etc/httpd/conf/ssl.key]# mv MYdomain.com.key MYdomain.com.key.has-passphrase [root@yourserver /etc/httpd/conf/ssl.key]# openssl rsa -in MYdomain.com.key.has-passphrase -out MYdomain.com.key
Restart apache (i.e. /etct/init.d/httpd restart)
[edit] Optimize Apache Memory Use
Apache is typically set up to provide a powerful, flexible configuration at the cost of system resources. For a high-traffic site these resources can quickly be consumed. Minimizing the resources allocated is important, so here are some tips to lower Apache's memory use.
[edit] Reduce your modules
If you haven't taken a look at your apache config's modules section recently, look again. Each module takes up a small piece of memory, which in certain configurations (ex. prefork) may take up more memory per apache child process. Indeed, each module may link against more libraries which may take up more memory. It's a good idea to only include the modules your application or apache config will need to function and nothing more. If you're comfortable getting your hands dirty compiling applications, go through apache and compile in only the modules and features you'll need. It's up to you if you want to disable dynamic modules entirely.
[edit] Calculating real memory use
When you look at your free memory with 'free -m' or 'top', do you expect those numbers to be accurate? Usually they're only useful for a general idea of how much memory may be used up. The reality is that applications don't always use as much memory as they tell the operating system they need, so real memory use appears higher than it is. Normally you'd look at the RSS - Resident Set Size - which is the amount of memory in RAM.
The problem is that this number is commonly higher than the amount of memory a particular process is using. The solution to this came in the 2.6.16 kernel as an 'smaps' file associated with every process. This file maps out both the shared memory and the 'private' memory of each process on the system. Since the shared memory consists of memory used by more than one process, the only good gauge of our real memory use is the private rss. If you add up the private rss of each process you get the total amount of memory in RAM that your processes are actually using. There are some scripts used to calculate this such as ps_mem.py and meminfo.pl, and a perl module Linux::Smaps you can use to calculate it yourself.
The end result is a better idea of how much memory each apache process takes up. Whereas 'top' may tell you the process is around 40MB, a smaps-parsing script may calculate the real memory use per process as 10MB. In a prefork apache set-up this would allow you to quadruple the number of child processes you can allocate. It's important not to over-commit your memory, though, or you risk going into swap and loading your node too much.
[edit] Getting crazy - Using a smaller C library
This is not for the faint of heart. If you're willing to experiment a bit and comfortable compiling applications, this may reduce your memory use. Go download, compile and install uClibc. It's a C library primarily intended for embedded environments (thus there is a focus on reduced memory use). If you cross-compile Apache against this C library instead of Linux's standard glibc, you may notice a significant decrease in the size of the resultant binaries. This does not mean that the memory use of the application will reduce - more than likely the data/code size in memory will remain the same. But the size of the executables loaded and running will reduce, which could give you a slight advantage when loading lots of modules or libraries. You'll need to also compile php and other dependent libraries with uClibc, so a system such as Gentoo may be ideal for this set-up. You can also download or compile a Buildroot to contain apache in its own uClibc-sandboxed environment. *WARNING* I have not actually run Apache on such a system and cannot vouch for its effectiveness. Consider this an experimental last step, but a possibility nonetheless.
