はじめに

OpenBlocksシリーズは、小型、堅牢、低消費電力のLinuxサーバとして、さまざまな用途に活用いただいてきました。しかし、性能面に関しては、ネットワークのインフラや監視用途としては必要十分なものの、LAMPなどのリッチなアプリケーションを搭載しようとすると不満が出ることもありました。そのため、いつかこの点は改善したいと思い続けてきました。

本連載で前回ご紹介したとおり、2012年6月7日に2つの新モデルを発表しました。1つは従来の用途を見据えつつストレージ性能の向上や導入コストの低減を図った「OpenBlocks A6」（⁠以降、A6⁠）⁠、もう1つはCPUが1.33GHzのデュアルコアとなり最大4ポートのギガビットイーサなどの豊富なI/Oを備えた「OpenBlocks AX3」（⁠以降、AX3）です。いずれも従来のPowerPCからARMアーキテクチャに変更となり、性能・仕様の向上を図りつつも、低消費電力は維持しています。

今回は、OpenBlocksの基本仕様や使い方の解説を交えながら、実際のところどの程度性能が向上したのか、実機検証をもとに紹介していきたいと思います。

OpenBlocksのOS

OpenBlocksでは、x86サーバとは異なり、出荷時点で必ずOSがインストールされています。ARMアーキテクチャでは、x86のように共通のカーネルバイナリでさまざまなハードウェアを動かすことはできず、ハードウェア専用のカーネルバイナリが必要となります。OpenBlocks Aファミリでは、この専用カーネルとDebian GNU/Linux 6.0のユーザランドを結合したファームウェアをあらかじめ本体基板上のフラッシュROMに書き込んであります。

そのため、サーバでありながら、製品購入後にOSをインストールする手間がなく利用でき、設定を初期化したいというときもコマンド1つで設定情報を消去したり、ボタン1つで初期設定状態で起動させることもできます。一見地味ですが、使ってみるとさまざまな面でとても便利なしくみを実現しています。もちろんカーネルなどの更新の際には、フラッシュROM内に格納したファームウェアも更新可能です（deb形式のパッケージで当社リポジトリから配布します⁠）⁠。

ストレージなしでも稼働可能

SSDを搭載しない場合、ファームウェアに含まれるDebianのユーザランドは本体メモリの一部を使って作成するRAMディスク領域に展開して/（ルート）パーティションとします。RAMディスク状態でも、apt-get/aptitudeによるソフトウェアの追加・更新が可能です。ただし、このままでは再起動でリセットされてしまいますので、変更内容の保存が必要となります。

フラッシュROMには、ファームウェア用の領域以外にユーザが自由に書き換え可能なユーザエリアを用意しています（AX3は50MB程度、A6は30MB程度⁠）⁠。変更内容は専用のコマンドでユーザエリアに保存することで、起動のつどフラッシュROMからRAMディスクに展開し、環境を復元できます。データの蓄積が不要な用途であれば、SSDの書き換え寿命や突然の電源断によるファイルシステムの破損の可能性を考える必要がなくなり、より堅牢なシステムを構築できるようになります。

初期セットアップ

OpenBlocksには、x86サーバのようなキーボード、ビデオ、マウスを接続するポートがありません。設定はルータやネットワークスイッチのように、シリアルコンソールやSSHを用いて行います。シリアルコンソールやSSHの接続は、WindowsであればTera Termやputty、UNIX/Linuxであればcuやscreen、sshなどが利用しやすいでしょう。

接続が済んでしまえば、あとはDebianの操作そのものです。性能向上も相まって、アーキテクチャの違いをほとんど意識することなく利用できるものと思います。Debianに不慣れな方のために、最初に行うべき設定内容や目的別の設定方法をCookbookと称して公開していますので、ぜひご覧ください。

パフォーマンスの比較検証

さっそく、比較検証を実施していきます。表1の機器で同一の試験を実施し、そのパフォーマンスを比較します。機器は新モデルのAX3とA6、一世代前のOpenBlocks 600D（以降、600D⁠）⁠、AX3の導入において比較されることを想定したAtomベースのx86サーバを用意しました。

性能測定は、おもにAX3の用途として想定しているWebサーバとして利用した場合のほか、ストレージとCPU性能のベンチマークを測定しています。CPU性能については、A/B/Cの各OpenBlocksの性能差の参考情報として用意しました。

Webサーバとしての性能比較

静的HTMLファイルを配信するWeb（Apache）サーバ環境を構築し、毎秒のアクセス性能を測定しています。測定にはApache Bench（abコマンド）を使用し、並列100リクエストを計10,000リクエストのHTTP接続で測定しています。結果は表2にまとめています。

ab -c 100 -n 10000 http://IPアドレス/

AX3と600Dの比較では、クロック数の差以上の結果となっており、性能向上がよくわかるかと思います。A6と600Dとの比較も、クロックは同じですが倍近い結果となっています。Atomサーバとの比較は、AX3でもさすがに力及ばずですが、違いはクロック差どおりとなっており、同クロックのAtomサーバであれば拮抗した結果になったかと思います。

ストレージの性能比較

今回は、Debianパッケージとして用意されている「fioパッケージ」を利用してストレージの性能を測定しています。表1の構成にあるストレージを/mntにマウントしたあとに、図1に記載した方法で測定しています。結果は表3にまとめています。

600Dの遅さが目立ちますが、ほかは項目によって得手不得手はあるものの、リード（READ）性能はシーケンシャル・ランダムともにOpenBlocksがAtomサーバよりも良い結果となりました。

# cp /usr/share/doc/fio/examples/ssd-test .
# vi ssd-test
directory=/mount-point-of-ssd

 ↓ 書き換え 

directory=/mnt
# fio ssd-test

CPUの性能比較

CPUの性能比較には、CPU演算性能を測定する「UnixBench」を利用しました。これはパッケージが用意されていないため、それぞれの環境でコンパイルする必要があります（図2⁠）⁠。CPU性能については、各OpenBlocksの性能差の参考情報として用意しました。結果は表4にまとめています。

# aptitude install make gcc perl
# wget http://byte-unixbench.googlecode.com/files/UnixBench5.1.3.tgz
# tar xvzf UnixBench5.1.3.tgz
# cd UnixBench
# make

AX3のOS/ハードウェアについて

比較検証の結果を踏まえ、AX3の性能に関わる話として、OSとハードウェアについて簡単に解説しておきます。

性能比較ではAtomサーバと比べてもそれなりの結果を確認できましたが、実はこの環境ではまだ性能をフルに発揮しているとは言えません。ARMアーキテクチャに限った話ではありませんが、ソフトウェアをコンパイルする際にはCPUの種別に合った最適化のオプションを指定しないと、どの世代のCPUでもサポートしている古い命令セットを使ってバイナリが生成されます。幅広い環境で使われることが想定されるソフトウェアでは、性能よりも確実な動作を見込んで意図的に古い命令セットが使われる場合もあるかと思いますが、その反面、新しいCPUでサポートしている効率的な機能を使っていないため実行速度が十分に出ない場合があります。

AX3の場合、搭載しているMarvell社のARMADA XPがARMv7命令に対応していますが、Debian 6.0のarmelアーキテクチャのバイナリはARMv4T命令となっています。バイナリを確認した結果は、図3のTag_CPU_archをご覧ください。また、この結果だけではわかりませんが、浮動小数の処理にハードウェアFPUを使うかどうかも重要な違いです。図3の環境ではソフトウェアエミュレーションで処理しているため、これも実行速度が遅くなる要因です。

# readelf -a /bin/bash | tail -12
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "ARM9TDMI"
  Tag_CPU_arch: v4T
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align8_needed: Yes
  Tag_ABI_enum_size: int

x86アーキテクチャでは、1989年のi486からハードウェアFPUがCPUに統合されるようになっていたため、普段コンピュータを利用するうえでFPUを意識することは少ないかもしれません。「⁠サーバとして使うときに、浮動小数点演算の処理性能が関係するの？」といった質問をいただくこともあるのですが、LAMPアプリケーションをはじめとした各種インタプリタ言語を利用したアプリケーションでは、変数型の自動変換を行う関係上、利用を意識せずとも内部的には浮動小数として扱われていることも多く、必要不可欠の機能となっています。ほかにもOpenBlocksでは、その壊れにくさが評価され監視用途で使われることも多いのですが、監視結果を可視化する際に画像描画が必要になる場面があります。この場合にもハードウェアFPUの有無が性能に大きな影響を及ぼします。

ではどうすればよいのかというと、必要なパッケージを最適なオプションを指定して自らコンパイルするという手段が考えられます。しかしながら、関連パッケージも含めて多岐にわたるため、あまり現実的な解とは言えません。やはりディストリビューション側で対応してくれているものがあればユーザとしてはそれが一番楽に利用できるわけで、その候補の1つが、Debian sid[1]のarmhfアーキテクチャです。

Debian sid/armhfとは

armhfのhfは、Hard Floatを意味しており（armelのelは、Little Endian⁠）⁠、ハードウェアFPUやARMv7の命令セットなどを利用したバイナリを提供しています。現在は不安定版のsidで利用でき、将来は次期バージョンのWheezy（7.0）で利用可能になるようです。

図4は、この環境で図3相当のバイナリ情報の確認を実施した結果です。Tag_CPU_archの結果がv7に変わり、Tag_ABI_HardFP_useやTag_VFP_archなどのハードウェアFPU関連の項目が増えていることが確認できます。

# readelf -a /bin/bash | tail -18
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "7-A"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_VFP_arch: VFPv3-D16
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align8_needed: Yes
  Tag_ABI_align8_preserved: Yes, except leaf SP
  Tag_ABI_enum_size: int
  Tag_ABI_HardFP_use: SP and DP
  Tag_ABI_VFP_args: VFP registers
  Tag_DIV_use: Not allowed

命令セットの違いとハードウェアFPUの使用の有無に着目して比較するため、各環境でUnixBenchを実行した結果を表5にまとめました。項目によっては低下もありますが、整数演算を示すDhrystoneの項目ではおよそ16％、倍精度浮動小数点演算を行うWhetstoneの項目ではおよそ950％（9.5倍）の向上となっており、効果のほどがおわかりいただけるだろうと思います。

これだけの差が確認できると、ぜひ標準として採用したいところですが、現状はあくまでも不安定版としての公開であるため、弊社としてはDebian 7.0でのarmhfのリリースを心待ちにしながら、ハードウェア性能を最大限に引き出せるほかのディストリビューション[2]の検証も並行して進めていきたいと考えています。有益な情報は製品の開発総合サイトやOBDN（OpenBlocks Developer Network）マガジンのブログで公開していきます。

まとめ

今回の性能比較によって、新しいOpenBlocks AファミリがAtomサーバを超えるまではいかないものの、従来製品と比べても大きく飛躍したことが確認いただけたかと思います。また、ソフトウェアの変更による今後の性能向上もあります。以前からご存じの方も初めての方も、新たなOpenBlocksをぜひお試しください。