Last week I did a lot of debugging on the Debian server to try and find out what was the issue. And initially it was Dovecots memory usage. After disabling this tool for a couple of days the server was still running fine. However the day after I posted the article on Dovecot the server crashed again. So I had to restart my investigation.

First off I had to had to get a better memory management tool, so I installed Htop on the server (apt-get htop). This shows the current memory usage of each running application. After installing this I enabled all services and applications again and started running stress tests. And though Dovecot was causing some peeks in memory usage it did not keep the high memory usage after the requests where done.

As it turns out for some reason Apache 2.2 was using a lot of memory during peak loads. But even more frustrating it didn’t seem to release any memory any more. Which was causing issues for services that only spawn when they are being accessed like Dovecot and Postfix, which explained why both of these services crashed when the server halted.

After tweaking the maximum amount of servers Apache is allowed to start and the maximum amount of client threads to handle the memory usage dropped dramatically. And I am very happy to report that the server has been running again for more then a week, without any glitches.

Still it doesn’t explain why all of this only happened after updating my server with the latest versions and patches. But I’m glad it’s solved for now.

Why I believe that dovecot is slowely over time eating up memory, well after I disabled it the VPS continued running without any issues. I already knew Apache 2, subversion and MySQL weren’t causing it. So I only had postfix and dovecot left to test.

What is truly amazing is that the website for Dovecot indicates it is low in memory consumption, hence it has no settings to limit the amount of memory allocated for Dovecot. So I still need to figure that part out, or alternatively change to a different IMAP server.

Now off course it is not the fault of Linux , but with my very lacking skill. I recently did an apt-get upgrade command on the VPS. To my suprise it started updating with Lenny packages, whilst I could have sworn I have Etch installed. Mystery on its own, but worse yet the server now keeps hanging and breaking.

I figured it was a memory issue at first cause some weird service was installed that was eating it alive. So I de-installed that and it ran fine for a few days. But allas, after 3 days of running the VPS hangs itself up again. When I say hangs-up I mean that I cannot connect using SSH, the mailserver goes down. MySQL and Apache keep running though, as does postfix. So I’m still guessing it is memory, but I have no idea why my configuration is no longer working after running an apt-get upgrade command. Something is really wrong .

I have my own root certificate for all of my websites, so that I can sign my own certificates and use them all over the place. I only have to ask my clients to accept the root certificate and all is fine. This seems to work fine except when I tried to load them into Apache. Here’s what my problem is and was. I have multiple domains hosted on the same virtual server. Which basically means a lot of websites running under one IP-address.

In this setup I have several domains I want to add a SSL variant of. For example webmail.domain.com as well as admin.domain.com. And this is where it became problematic.

I configured this without any problems in apache. Setup a virtual host listening to port 443 and setup the listener instruction in apache. But for some reason all of my secure domains ended up using the same certificate. Which off course causes a lot of security warnings for the browsers . And a lot of people are having the same issue, just read the thread on howtoforge.com.

As it turns out Apache is only able to host one secure virtual host per IP-address and port combination. Which is kinda obvious since Apache cannot read the domain name until it has decrypted the SSL information, something which it cannot do until the SSL handshake with the client has been done. Hence that only one set of certificates is allowed per IP and port.

Long story short I ended up setting the websites up with different ports since I don’t have multiple IP-addresses to host the websites on.

Keep in mind the average page size is not only the size of the HTML but also adding the external CSS, JavaScript and images. Which could dramatically increase the amount of data the users are downloading. So I started looking in the compression options of Apache 2.0

First I looked on the official Apache page, but as usual the data is probably available but not very user friendly. So after some testing and crashing I found out the following procedure which seems to work fine to enable compression per Virtual Host.

Firstly enable the module that supports compression by executing:

:> ln -s /etc/apache2/mods-available/deflate.load /etc/apache2/mods-enabled/deflate.load

This will instruct Apache to load the needed library (module) for compression using GZip. The second thing you will need to do is add the following lines to every single Virtual Host you want to use compression on.

    <Location / >
      SetOutputFilter DEFLATE
      BrowserMatch ^Mozilla/4 gzip-only-text/html
      BrowserMatch ^Mozilla/4\.0[678] no-gzip
      BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
    </Location>


This will enable the compression for output (everything sent to the end-user) but not for incoming requests, which in my case is enough compression for right now. It also exludes some browsers that do not support compression.

Now restart or reload your apache by running the statement below and your website should support compression. This will make the loading of pages faster, though the client software needs to decompress the pages from this point on.

:> etc/init.d/apache2 reload

If you have any trouble enabling compression just leave a message and I’ll try and help you where I can.