Servers vs Phones

Hetzner have recently updated their offerings to include servers with 16G and 24G of RAM [1]. You can get a dedicated server with two 3TB SATA disks, an i7-2600 quad-core CPU, and 16G of RAM for E49 per month plus an E149 setup fee. That is a good deal and I’ll probably soon be running a few more servers at Hetzner because of it.

HTC is currently offering five different Android phones that have 1G of RAM [2]. So while Hetzner is offering some great deals on dedicated servers, the affordable option has 16* the memory of a modern phone and the high-end option and the biggest option has a mere 24* the RAM of a phone!

Linode is a virtual server provider that I’m using for some of my clients, they offer virtual servers with 20GB of RAM for $US800 per month [3]. That doesn’t compare well to Hetzner’s offer of 24G for E59 ($US81) per month. Admittedly the management interface for Linode is really good while the process of recovering from a Hetzner server with a serious configuration issue is painful – but getting two Hetzner servers in some sort of HA configuration would be 1/5 the cost of a Linode virtual server.

HTC offers two Android phones with 16G of built-in flash storage that have the ability to take a 32G microSD card for a total of 48G of storage. Linode’s smallest virtual server plans have 20G, 30G, and 40G of storage, so a modern phone can store more than twice as much data as the smallest Linode plan and more data than any of the three smallest plans.

While it’s obvious that phones don’t perform well for any real server use (lack of fast network access, disk IO speed, and CPU power being obvious issues) it does seem that the recent announcements of newer cheaper server plans aren’t that exciting when compared to mobile phones. For a similar monthly rate I could get a mobile phone “free” on a two year contract or a Hetzner server that has 16* the RAM.

It’s a pity that Hetzner does’t offer servers with up to 128G of RAM and more than four disks. RAM isn’t THAT expensive nowadays and their business model includes having the customer pay for various options that other companies don’t tend to offer in a similar price range (such as SSD and other hardware customisation).

Also see XKCD’s comparison of HDTV and mobile phones [4].

4

Akonadi on a MySQL Server

Wouter described how to get Akonadi (the back-end for KDE PIM) to use PostgreSQL [1].

I don’t agree with his “MySQL is a toy” sentiment. But inspired by his post I decided to convert some of my systems to use a MySQL instance running on a server instead of one instance for each user. In the default configuration you have 140M of disk space and 200M of RAM used by each user for a private MySQL installation which has about 24K of data (at least at the moment on systems I run, maybe more in future).

Here’s some pseudo shell script to dump the database and get a new config:

mysqldump --socket=$HOME/.local/share/akonadi/socket-$HOSTNAME/mysql.socket akonadi > dump.sql
akonadictl stop
rm -rf .config/akonadi
rm -rf .local/share/akonadi
mkdir .config/akonadi
cat > .config/akonadi/akonadiserverrc <<EOF
[%General]
Driver=QMYSQL
SizeThreshold=4096
ExternalPayload=false

[QMYSQL]
Name=${USER}_akonadi
Host=IP_OR_HOST
User=$USER
Password=$PASS
StartServer=false
Options=
ServerPath=/usr/sbin/mysqld

[Debug]
Tracer=null
EOF

Then with DBA privs you need to run the following in the mysql client:

create database $USER_akonadi;
GRANT ALL PRIVILEGES ON $USER_akonadi.* to '$USER'@'%' IDENTIFIED BY '$PASS';

Then run the following to import the SQL data:

mysql $USER_akonadi < dump.sql

Ideally that would be it, but on my test installation (Debian/Squeeze MySQL server and Debian/Unstable KDE workstations) I needed to run the following SQL commands to deal with some sort of case problem.
rename table schemaversiontable to SchemaVersionTable;
rename table resourcetable to ResourceTable;
rename table collectionattributetable to CollectionAttributeTable;
rename table collectionmimetyperelation to CollectionMimeTypeRelation;
rename table collectionpimitemrelation to CollectionPimItemRelation;
rename table collectiontable to CollectionTable;
rename table flagtable to FlagTable;
rename table mimetypetable to MimeTypeTable;
rename table parttable to PartTable;
rename table pimitemflagrelation to PimItemFlagRelation;
rename table pimitemtable to PimItemTable;

I am not using any PIM features other than the AddressBook (which hasn’t been working well for a while), so I’m not sure that this is working correctly. But I would prefer that something I don’t use and is probably broken take up disk space and RAM on a server instead of a workstation anyway.