dalescott.net is back down from the cloud!

Hosting dalescott.net on a low-cost  cloud server didn’t go so well and I had to move my site back to a bare metal server in the basement.

Step 1

It all started when I created a $5/month FreeBSD 10.1 vps using a DigitalOcean droplet (1 CPU, 512MB RAM) to host a demo for my Maestro PLM/ERP project. The site also included OpenLDAP/phpLDAPadmin and Postfix/dovecot/procmail/mutt/SquirrelMail for Swift Construction Company demo user authentication and email. The vps was rock solid, and I was very pleased with performance and cost (although getting negligible traffic).

Step 2

A year later, I tried to simplify my life by migrating my WordPress blog from a bare metal server in the basement also to the DigitalOcean vps droplet. The blog went live on the vps once I updated the IP address for my dalescott.net domain using No-IP’s DDNS service, and a day later the system was non-responsive with kernel out-of-swap errors in /var/log/messages. My immediate response was to dedicate 2G of the available 20GB SSD file space to swap (3GB total swap), but this only delayed the system becoming non-responsive to ~3 days.

I next learned how to tune the apache prefork mpm to not use more than ~300MB memory. At first, everything seemed OK and I breathed a sigh of relief, not too responsive but at least not running out of RAM and thrashing.  Then I upgraded some ports and upgraded from FreeBSD 10.1 to 10.3 (or maybe from 10.2 to 10.3, I regret not keeping better notes), but the result was that the server couldn’t maintain an ssh connection for more than 30 seconds with Apache running.

Rebooting and watching the system console, I noticed a ZFS notice I hadn’t noticed before – warning of expected unstable behaviour!

ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable......
ZFS WARNING: Recommended minimal kmem_size is 512MB; expect unstable behavior....

I also noticed errors in /var/log/messages that I didn’t recall seeing before.

dale@whizzer:~ % tail /var/log/messages
Aug 25 16:05:33 whizzer dale: /usr/sbin/service: WARNING: $growfs_enable is not set properly - see rc.conf(5).
Aug 25 16:05:33 whizzer dale: /usr/sbin/service: WARNING: $ is not set properly - see rc.conf(5).
Aug 25 16:05:33 whizzer dale: /usr/sbin/service: WARNING: $rsyncd_enable is not set properly - see rc.conf(5).
Aug 25 16:05:33 whizzer dale: /usr/sbin/service: WARNING: $php_fpm_enable is not set properly - see rc.conf(5).
Aug 25 16:05:33 whizzer dale: /usr/sbin/service: WARNING: $htcacheclean_enable is not set properly - see rc.conf(5).
Aug 25 16:05:33 whizzer dale: /usr/sbin/service: WARNING: $git_daemon_enable is not set properly - see rc.conf(5).
Aug 25 16:05:33 whizzer dale: /usr/sbin/service: WARNING: $dbus_enable is not set properly - see rc.conf(5).
Aug 25 16:05:33 whizzer dale: /usr/sbin/service: WARNING: $avahi_daemon_enable is not set properly - see rc.conf(5).
Aug 25 16:05:33 whizzer dale: /usr/sbin/service: WARNING: $avahi_dnsconfd_enable is not set properly - see rc.conf(5).
dale@whizzer:~ %

DigitalOcean now has both FreeBSD “10.3” and “10.3 zfs” droplet templates, and I had recently upgraded the system to 10.3 using “pkg upgrade”. Could there be some unexpected interaction between my manually updated system and DigitalOcean’s droplet management scaffolding?

DigitalOcean tech support was supportive and tried to help, but in the end recommended starting over.

…it’s always going to result in some issues if you upgrade a Unix system’s distribution release in-place. We see it a lot in the Linux images where a release upgrade causes some random issues down the road, and upgrades tend to not work as well as anticipated. We would recommend setting up a newly built Droplet running the release you require and then to plan your migration of applications or data onto that new system.

I was disappointed with the recommendation to start over, especially as FreeBSD is well known for being able to update in-place. Not being able to update the OS might be OK for short-lived dev servers, and maybe for production servers with a team of people to do the work when upgrading is necessary, but it was not what I was expecting.


In the end, the decision to re-host back to my own server came down to performance, anticipated future maintenance effort, and cost. Page loading was never really as good as I wanted, especially after restricting Apache to available RAM (although at least it stayed somewhat responsive). I also didn’t look forward to having to repeat the server migration when I was ready to upgrade to FreeBSD 11.0.

Already having a suitable server on hand (a de-branded HP media tower with an Intel 2×2.3 GHz CPU, 3 GB RAM, two 400GB drives), I installed FreeBSD 10.3 and started the migration. I’ll keep the droplet for experimenting, but for now it’s back to the basement for dalescott.net.


Transparency with Trust

FreeBSD and Apache on a $5/month DigitalOcean Droplet VPS

I recently merged dalescott.net and swiftconstructioncompany.net onto a $5/month DigitalOcean droplet (512MB Memory, 1 Core Processor, 20GB SSD Disk, and
1TB Transfer). Afterwards, I wanted to get a measure of server performance. A quick web search came up with some candidates:

  1. Load Impact, claiming “The leading on-demand load and performance testing software-as-a-service.”
  2. Neustar, who claims “We started it all. And we continue to shape the industry.”
  3. WebPageTest, created by AOL for internal use before being open-sourced and now primarily developed and supported by Google.

There are more, but these will be enough to get started with. I had wanted to include Blitz.io, which was referenced in a blog post by Ryan Frankell on using Apache on a small DigitalOcean droplet . However, I couldn’t find any free evaluation capability, and Blitz’s demo is hard-coded to use a Blitz demo site, which eliminated Blitz from consideration.

Tuning Apache

The first step was to tune Apache. 512MB of RAM is low by server standards and also Apache’s default configuration. Some tuning is needed to keep Apache operating in the available RAM, otherwise Apache will gradually consume everything, including swap, and eventually the kernel will start thrashing.


KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5

The FreeBSD apache24 port already sets these as defaults in /usr/local/etc/apache24/extra/httpd-default.conf  (the default MaxKeepAliveRequests is even lower than the recommended 200).



Although Event is reportedly the default MPM in Apache 2.4, Prefork is still the default on FreeBSD 10.x for compatibility with non-thread-safe php/perl/python modules.

MaxRequestWorkers and MaxConnectionsPerChild must be lowered in /usr/local/etc/apache24/extra/httpd-mpm.conf, and the Include line for httpd-mpm.conf in usr/local/etc/apache24/httpd.conf must be un-commented (and Apache restarted).

# prefork MPM
# StartServers: number of server processes to start
# MinSpareServers: min number of server processes which are kept spare
# MaxSpareServers: max number of server processes which are kept spare
# MaxRequestWorkers: max number of server processes allowed to start
# MaxConnectionsPerChild: max num of connections a server process serves
# before terminating
#<IfModule mpm_prefork_module>
#    StartServers 5
#    MinSpareServers 5
#    MaxSpareServers 10
#    MaxRequestWorkers 250
#    MaxConnectionsPerChild 0

<IfModule mpm_prefork_module>
 StartServers 5
 MinSpareServers 5
 MaxSpareServers 10
# reduce max number of server processes to not exceed physical memory
# called "MaxClients" prior to v2.3.13 (MaxClients is still supported)
# - uses cache under load when 25
# - appears to not use cache under load when 12
 MaxRequestWorkers 12
# reduce max connections per child to avoid idle processes from holding onto memory
# - memory use seems stable when 200 but could be lower than optimal
# MaxConnectionsPerChild 350
 MaxConnectionsPerChild 200


Load Impact

I first used the free no-login-required test, which loads 25 Virtual Users in 5 minutes, but by creating a free login profile you are allowed 5 (QTY)-five minute tests (executions) up to 100 VUs per month. Here are the results of the Load Impact test with Apache tuned, showing load times in the low seconds for up to 15 users. This can likely be further improved, but the server is stable and adequate for the expected amount of traffic.

2016-08-12 LoadImpact test results



Neustar queued three servers for testing, but the Washington server never ran. Here are the results when I gave up waiting.



WebPageTest concentrates on measuring how fast it takes a page to load, and gives lots of information for digging into the load times for each aspect of the page. I was looking for more of a general load or stress test to see if my server will fail under load, but the information can be valuable none the less.


Server Performance

Here are the result of top while the Load Impact no-login (20 VU) test is running. Although the server can by no means be considered fast, it also is not exhausting swap and stalling. I’m pleased for now, and will be back to review when time permits.