WordPress on Raspberry Pi 2 running Slackware ARM

Two weeks ago, I decided to move this blog from its old hosting and deploy it on a Raspberry Pi 2. The geek in me could no longer resist the urge to discover if a $35 worth computer could replace the need for commercial hosting. Besides, what a great opportunity to finally get my hands on Slackware’s official ARM port.

RPi2 setup:

Raspberry Pi 2 Model B
Raspberry Pi 2 Micro USB Power Cable 1.2A
MicroSDHC Ultra UHS-I 32GB

LAMP setup:

Slackware ARM current
Package series: a, ap, d, l, k, n (and a few from “x”).
Apache 2.4.12 (rebuilt)
MariaDB 5.5.40 (rebuilt)
PHP 5.4.40 with mod_proxy_fcgi and php-fpm (rebuilt)

Non stock packages:
Modsecurity 2.9.0
Fail2ban 0.9.1

Why use Slackware and not a hard float port?

A hardware floating-point unit you say, well I’d never heard of it.

ARMv7 includes a hardware floating-point unit (FPU), with improved speed compared to software-based floating-point. http://en.wikipedia.org/wiki/ARM_architecture

In short, Slackware is not optimized for modern ARM implementations and it would be reasonable to assume that performance could be improved on a hard float port.

WordPress performance out of the box

It was not great truth to be told, page load times using the twenyfifteen theme clocked in at around 2.5 seconds on average (using 17 queries). I’ve always believed WordPress to be a “lightweight” application, but I guess that’s up for debate. Anyhow, I decided to try my hand at overclocking the RPi2 to see if I could improve performance to something more sustainable for production.

RPi2 final config:

force_turbo=1
arm_freq=1000
core_freq=500
sdram_freq=500
over_voltage=6
temp_limit=75
gpu_mem=16

I tried to push the arm_freq higher, but that caused the RPi2 to cough and crash under high load. Pushing the RPi2 to its limit sliced off another second of page load time, which was good, but obviously not comparable to commercial hosting. It was pretty much as expected, but it still felt like somewhat of a disappointment. However, since I rely heavily on caching with any WordPress installation, this RPi2 was not out of the game yet.

Optimizing the environment

By installing the “WP Super Cache” plugin from Automattic, and optimizing Apache for serving cached and compressed content, the RPi2 turned into a regular powerhouse.

Latest Performance Report for: www.blog.paranoidpenguin.net
Latest Performance Report for: www.blog.paranoidpenguin.net

Analyzing the performance over at GTmetrix.com gave me a page speed score of 96% and a YSlow grade of 92%. That’s a decent result on any platform and I’m rather impressed with the performance of the Raspberry Pi 2 in that regard.

The fact that the RPi2 is sitting on my desk while being assigned a dynamic IP, instead of cooling off at a high tech data center  with next to unlimited bandwidth makes it even more enjoyable.

I have one sour note though, compiling software is painfully slow, but that should not come as a huge surprise.

Onwards

This site will keep rolling on Raspberry Pi 2 and Slackware ARM until something breaks beyond repair. As Slackware current is ripe for an avalanche of updates that might be sooner than later. If that should be the case, then I’ll update the changelog with the latest turn of events.

Slackware ARM current hosting blog.paranoidpenguin.net
Slackware ARM current – Now hosting www.blog.paranoidpenguin.net

Slackware ARM on the Raspberry Pi 2 – 38 days later

Excited by the prospect of hosting my blog on the new Raspberry Pi 2, I decided lately to wave goodbye to the local datacenter and unleash a Slackware Linux box into the wild (full story here).

Everything went (mostly) without a hitch until I wanted to get back in sync with the Slackware-current tree. After applying the available updates and issuing a reboot, the system seemed operational and nothing from the logs gave any indication of imminent failure.

Vmscan.c - Linux VM subsystem
Bob, we have a problem!

The next morning however, the system was unresponsive and syslog seemed to point to the kernel swap daemon, complemented with page allocation errors and a flood of stalls on CPUs/tasks from RCU.  To make matters worse, the system would completely lock up during troubleshooting.

Forcing fsck on all partitions revealed errors on both the FAT32 /boot partition (dirty bit) and the /(root) ext4 partition (multiply-claimed blocks in inode). I suspect these errors were caused by overclocking the RPi2 to its limit as it seem the system might not have had time to sync changes to disk before shutting down.
In hindsight, I remember that I experienced data corruption with one PHP file in the WordPress installation directory, but at the time I blamed it on a borked upgrade. I should probably have taken it as a sign of troubles to come.

RPi2 modified config:

arm_freq=1000
sdram_freq=500
core_freq=500
over_voltage=2
Raspberry Pi 2 Model B
Powered by SARPi2

After implementing these changes, a week has gone by without any more issues. Easing up on the overclocking means PHP execution is back to a crawl, but that’s what caching is for I guess.

Anyhow, the dream of independent hosting with Slackware ARM on the Raspberry Pi 2 lives to see another day.

This is not the page you’re looking for!

ModSecurity
ModSecurity: The Open Source Web Application Firewall

I’ve become aware that lately, a number of legitimate visitors have been blocked by ModSecurity and handed the “This is not the page you’re looking for!” message.

I seem to have done a half-baked job of examining the logs to remove false positives. To make matters worse, I whitelisted my own network so I never actually triggered any blocks myself.

Anyhow, ModSecurity is an awesome product and not to blame. Even the finest piece of software can’t defend against clueless user configuration.

My apologies for any inconvenience!