Ubuntu 14.04 and Sentora as a small hosting solution on a cheap VPS (Part 2)

If you followed the previous post, you will now have a fully working Apache web server, with PHP5, MySQL data bases, FTP accounts, Dovecot and and Postfix all controlled by an easy to use panel on a $5 per month VPS! You may have uploaded a website or two, and then all of a sudden, out of the blue

Critical Error: [0100] – Unable to connect or authenticate to the Sentora database (sentora_core).

…or another similar error. Basically, the panel has gone down and you will probably find that any website that relies on a database is also throwing out errors. The server has run out of available memory, so MySqld bit the bullet and died 🙁 What a hero! Now obviously we could just restart this service and be on our merry way, but with only 512MB of RAM this is going to keep happening. In fact with less than 2GB of RAM, a default Sentora install will probably fall over without some tweaks, so what chance does our piddly-little 512MB server have? First things first, let us give it a fighting chance.

Set up a swap file. (not recommended on SSD storage)

In most server environments, setting up a swap file can actually hurt performance but in a memory-tight environment one can be used to help with low memory (or no memory) situations like ours. A rule of thumb would be to keep this file no bigger than twice the amount of RAM you have, so we will make a 1GB swap file. Connect to the server with SSH as root and run the following command

fallocate -l 1G /swapfile

This will create a 1GB file in the root directory called swapfile, now type

chmod 600 /swapfile

This will change the permissions of the swapfile so only the root user can read it. We now format the file as swap and activate it, the same way we would with a partition, type the commands

mkswap /swapfile
swapon /swapfile

The system will now start using the swap file but we need to make this change permanent. We can tell the server to use the swap file by editing the fstab file

nano /etc/fstab

And add the following line to the end of the file, on a new line

/swapfile   none   swap   sw   0   0

Exit with ctrl+x and press y to save the file. The system will now use the swap file on reboot and this should free up a small amount of extra RAM for our server to consume. While it is a good idea to have a swap file in this scenario, it is not a fix to all the problems. Under any more than light load, Apache will still consume all the memory available, MySqld will keep biting the bullet (although it might dodge a few this time) but there is still more we can do.

Tune Apache.

This is probably the biggest change we will make. Apache2 by itself would eventually consume all of the available RAM, and we have other services to consider. At least on this install, Apache is configured to use the mpm_prefork module which aims to keep performance high under load by spawning more than one Apache process to serve any requests made. We can lower the default and maximum processes by editing 2 files. Connect via ssh to the server as root and open the file /etc/apache2/mods-available/mpm_prefork.conf

nano /etc/apache2/mods-available/mpm_prefork.conf

Change the file so it looks like the one below

<IfModule mpm_prefork_module>
StartServers 1
MinSpareServers 1
MaxSpareServers 3
MaxRequestWorkers 10
MaxConnectionsPerChild 50
MaxClients 10
MaxRequestsPerChild 3000

Press ctrl+x to exit, and y to save the file, then open /etc/apache2/mods-available/mpm_worker.conf

nano /etc/apache2/mods-available/mpm_worker.conf

And change the file to look like the one below

<IfModule mpm_worker_module>
StartServers 1
MinSpareThreads 5
MaxSpareThreads 15
ThreadLimit 25
ThreadsPerChild 5
MaxRequestWorkers 50
MaxConnectionsPerChild 0
MaxClients 25
MaxRequestsPerChild 200

Exit the file with ctrl+x and press y to save the file. We now need to restart Apache so it knows to use the new settings with the following command

service apache2 restart

Apache will now reload and use these new settings, and will also consume much less memory than before. If you monitor the connections to the server, you will see Apache can still quite easily serve pages as before, even though the settings may seem quite low. In fact, the page you are reading right now is being served from such a server. This change will free up quite a lot of RAM by default, and should stop most crashes that happen but you may still find these services require a little more monitoring and for that we can use Monit.

Install Monit.

Monit is a great tool we can use to make monitoring the vital services of our server a bit easier. Not only can it alert you to our friend MySqld’s suicidal tendencies, it can also restart any services that do stop running. To install Monit, ssh into your server as root, and issue the following commands

apt update
apt install monit

Once installed we need to tell Monit which services to watch. Edit the file /etc/monit/monitrc

nano /etc/monit/monitrc

Find the line that reads  #set httpd port 2812 and un-comment the line (delete the #), and make these changes

set httpd port 2812 and
use address yourdomain.com # only accept connection from yourdomain.com
allow # allow connection from any ip
allow admin:password # require user ‘admin’ with password ‘password’

Go to the end of the file and insert the following section

check process apache with pidfile /var/run/apache2/apache2.pid
start program = “/etc/init.d/apache2 start” with timeout 60 seconds
stop program = “/etc/init.d/apache2 stop”
if failed host YourDomain.com port 80 protocol http then restart

check process mysqld with pidfile /var/run/mysqld/mysqld.pid
start program = “/etc/init.d/mysql start”
stop program = “/etc/init.d/mysql stop”
if failed unixsocket /run/mysqld/mysqld.sock then restart

check process postfix with pidfile /var/spool/postfix/pid/master.pid
group system
group mail
group postfix
start program = “/etc/init.d/postfix start”
stop program = “/etc/init.d/postfix stop”
if failed host localhost port 25 with protocol smtp for 2 times within 3 cycles then restart
if 5 restarts with 5 cycles then timeout

check process crond with pidfile /var/run/crond.pid
group system
group crond
start program = “/etc/init.d/cron start”
stop program = “/etc/init.d/cron stop”
if 5 restarts with 5 cycles then timeout

check process sshd with pidfile /var/run/sshd.pid
group system
group sshd
start program = “/etc/init.d/ssh start”
stop program = “/etc/init.d/ssh stop”
if failed host localhost port 22 with proto ssh then restart
if 5 restarts with 5 cycles then timeout

This will create a job that monit will use to monitor our needed services, you can add or remove services and customise the file more to create email alerts and to monitor other services, but these changes will be sufficient for most service crashes. Obviously you should monitor the services yourself too from time to time, and monit even provides a web page for doing this (even if Apache isn’t running) simply visit http://yourdomain.com:2812 and login with the username and password defined in the above example.

With the above changes, you should find your server behaves quite well even under-load. Some requests may take longer than others as Apache deals with traffic but overall should find that the pages load faster than your average shared web host. There are still things that could be optimised, and if the server becomes quite busy it really should be upgraded, but with a low usage scenario it should work fine for most hosting needs. Now that we have a working web server we can look into adding a few more features, this and more will be covered in Ubuntu 14.04 and Sentora as a small hosting solution on a cheap VPS (Part 3).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.