In my previous post I mentioned that I had and still am having some serious issues with the stability of the VPS I’m running all of my websites on. Though I’m still a long way away from solving the issue, I have figured out that it is very likely caused by an upgrade of Dovecot.
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.
I’ve heard a lot of people always say that you can’t crash/hang or break linux easily. Well then I guess I’m one of the lucky bastards that gets it done. Since a few days the VPS system I’m operating keeps hanging itself up.
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
.
As you may have been able to notice over the past week or so my websites and those I am hosting for clients had some down-time last week. As such I’ve not been doing much other then trying to figure out what is going on, and haven’t had to much time to write something new.
Unfortunattely for me and my clients the problem seems to be with the provider I have to rent my servers. After some digging I found out even their own servers where unreachable. (Could not even setup a SSH connection to my servers).
It seems to be fixed at the moment, so keep praying that it stays that way
.
As of late I started to notice my little VPS server had more difficulty keeping up with the amount of data it has to sent to the webbrowsers. I knew that the amount of requests increased and after some tracking I found out that the average page size also increased.
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.
You might have noticed it yesterday, or not
. But my blog and several other websites hosted by me went offline yesterday for a couple of hours. Well this had to do with me upgrading the VPS to Debian Etch.
So far I ran every website on Debian Sarge, and though it’s stable they choose to no longer developer for it nor support it. So it was time to move to a newer version. Wich I did yesterday. Here’s some of the steps you should take before upgrading to the next version of Debian.
I was lucky that my hosting provider offers an easy way to upgrade or reinstall a Linux distro on the VPS. Just a couple of mouse clicks and they prepare the VPS for the installation. Please note that this will take up to an hour to complete. Once this base installation is complete you will want to perform the following steps:
From this point on your ready to go. All of the websites should be running without any problems. You do need to configure any other tools you had installed, like AWStats / Subversion or anything else. Though these should not require to much configuration as all of the configuration files where included in your backup. At least if you followed a setup similar to my first article on setting up linux.