私は BIK - Aschpurwis + Behrens、ドイツの市場・メディアリサーチ研究所 (http://www.bik-gmbh.de) で働いています。 BIK では多種多様な Unix 派生の OS を使用してきました。SCO、NeXTStep、SunOS、Solaris、NetBSD、いくつかの PC ベースの SVR4、そして言うまでもなく FreeBSD です。
いかにして FreeBSD が職場の私のデスクでのお気に入りの OS になったのかという話はちょっと退屈だし、理由の大部分は個人的な嗜好の域を越えるものではありません。私は FreeBSD が一番良いと思った、FreeBSD は私の触った Unix 派生の OS の中でもっとも問題を起こさないものだったというだけの話です。これに関して、(私には) NetBSD だけが唯一のライバルでした。
いかにして FreeBSD がわが社のマルチユーザ・サーバ用のマシンのもっとも有力なプラットホームになったのかという話は、それよりいくらかは退屈ではないでしょう。
1990 年以降、我々は機能追加のためのフックをたくさん持った、バッチ指向の表作成プログラムを開発してきました。これはかなりちゃんとした製品になりましたが、GUI 好みのユーザには使うのが難しいものだったので、これを直接使用する外部の顧客はごく少数にとどまっていました。この製品は上記すべてのプラットホームで動きました。
World Wide Web が現れたとき、我々は突然、自分達が DOS/Windows や Macintosh でインタラクティブな表計算ソフトウェアを開発している競争相手よりもずっと良い位置につけていることに気が付きました。HTML 形式の入力を我々のプログラム用の記述に変換することも、結果を HTML で出力させることも簡単に実現できたからです。
必要な機能は簡単に追加することができたのですが、我々は大きなパフォーマンス上の問題に直面する事になりました。そして、私たちは、FreeBSD を使用すれば、アプリケーションに大幅な手直しを加えることなく、驚くほどジョブのスピードアップができることを発見したのです。
まず最初に、我々のアプリケーションは、長いレポート用に多量の表を出力できるよう最適化されていました。90 年代早期には、そのような出力は 30-45 分で終われば上等だと思われていました。しかし、WWW 中心の 1996 年の世界では、もっとずっと小さな表を出力する必要があります。我々はそのリミットを 7 秒に設定することにしましたが、この数字は新しいマシンを使っただけでは達成できませんでした。
我々は三つの問題に直面しました。
- CPU がディスクからデータが到着するのを待たずにビジーであり続けるためには、即時必要となる一部のデータだけを高速に取得する、何らかの手段を講じる必要がありました。
- 我々のアプリケーションは大きなデータ集合を扱うのみならず、一回の実行につき二度、(アセンブラやリンカを含む) C コンパイラを起動します。コンパイラの実行自体のコストに加え、我々は、大部分のシステムでは、コンパイル作業中にメインのデータ集合がファイルシステムのバッファキャッシュから追い出されること、したがって別の分析が始まる度に、データをディスクから再読み込みする必要があることに気が付きました。
- 我々には、もちろん、最大限の、最高級のディスクが提供するよりはるかに高いディスクスループットが必要でした。
- 我々のアプリケーションは単一のプログラムではなく、関連を持つプログラム群が実行の度に再起動される形を取っています。このコストは 30 分の分析では取るに足らないものでしたが、ウェブベースの製品では、すべてのプロセスが十分な速度で起動できるという確証が必要でした。また、我々はこのアプリケーションを、より多くのプロセスを起動する CGI アプリケーションとして実装したいという希望も持っていました。
もちろん、アプリケーション自体に変更を加えるのが、すべての問題に対する最良の解決策だったのでしょう。しかし、そのためには、本来は他の場所へ回す必要がある、プログラマの価値ある時間を割かなくてはなりません。アプリケーションに対するこの手の「修正」に抵抗が生じるのは、専門的なコンピューティングのほとんどの領域において、決して異常なことではありません。問題のアプリケーションが (あっという間に追加された HTMLのサポートも含めて) 「動いて」いる場合は特にそうです。
信じようが信じまいが、オペレーティングシステム自身が、この手の問題の多くを、アプリケーションに変更を加えることなく解決することができるのです。そう、FreeBSD は確かに我々の助けになりました。
最初の問題は、我々が大きなデータ集合から、ランダムに小さい部分だけを読んでいることでした。我々が試した他の Unix 派生の OS では、特定の (もちろん最適ではない) アクセスパターンに対して十分に効率的にはデータを転送することができませんでした。システムはディスク待ちで断続的にアイドル状態におちいるか、カーネル内部で (主にキャッシュの管理とデータのコピーによって)多くの時間を費やしていました。それらのシステムの mmap() には種々の問題があることもわかったのですが、多くのシステムは両者に当てはまったので、そこまで話を進める必要もありませんでした。しかし、FreeBSD は、必要とされるデータ片を、CPU 時間の 90% をアプリケーションで費やすに足る、十分な速度で転送してのけたのです。これは、我々をアプリケーションの重要な部分を書き直すことから救うには十分でした。
次の問題は、我々のアプリケーションが、メインのデータ集合にアクセスする前と後に C コンパイラを呼んでいることでした。我々が試した他のすべてのシステムでは、コンパイラの実行はデータ集合をディスクキャッシュから消し去る原因になっていました。同じデータを使う後続のアプリケーションは、データを再びディスクから取得する必要があり、結果としてパフォーマンスに大きな打撃を与えていました。それらのシステムでは、小さいファイルがアクセス中である場合、それより大きなファイルをキャッシュしておくことができないようで、メモリの追加でさえ十分な助けにならないように見えました。 また、別のキャッシュ戦略を取らせる方法もありませんでした。我々は最初、そのシステムを使うには、データ集合をメモリに収容し、そのデータを共有メモリを使って表作成プログラムに提供するための特別なプログラムを開発する必要があるのではないかと考えました。しかし、マシン上にはひとつ以上のデータ集合が存在しているので、ひとつのデータ集合がメモリをすべて占有するわけにはいきません。 それで、我々には、オペレーティングシステムのバッファキャッシュの機構を、異なった優先順位でジョブを処理するように書き直すしか方法がないようでした。まったく、もう!
ありがたいことに、FreeBSD を使うことで、すべての問題に議論の余地が生まれました。256MB メモリを載せた FreeBSD マシンでは、212 MB のデータ集合に対して複数の分析を実行することが可能で、しかも各分析間のコンパイル作業後でも、ファイルは依然としてキャッシュの中に存在しました。 おそらくこの振る舞いは、潜在的に他のアプリケーションのパフォーマンスを傷つけ得るものではあります。しかし、我々はその事例を発見することはできませんでした。これだけをとっても、FreeBSD は我々を何週間ものコード書き、テスト、パフォーマンス分析とチューニングの作業から解放してくれたのです。
ディスクのスループットも、もちろん、我々の作業にとって重要な部分です。そして、FreeBSD の ccd (ディスクのストライピング)ドライバは、我々にとって十分な価値のあるものでした。ディスクとコントローラをストライプドボリュームに追加した場合、連結されたファイルシステムから得られるパフォーマンスは、個々のドライブ上の単一のファイルシステムから得られるスループットの総計に非常に近くなります。 本当のところ、我々はもっとずっと低い数字を想定していました。RAID 的な機能を提供するものに、「それ、完璧にうまく走るとして、単一のディスクより速いの? 遅いの?」と尋ねてみるのは、ディスクの安定性よりスループットが必要な人には、やっぱり大事なことですね。
パフォーマンス上の強みに加え、FreeBSD は最も簡単に管理できる Unix システムであることもわかりました。
我々は、よくウェブのサービス用に追加のマシンを設定する必要にせまられるのですが、FreeBSD はディスクボリュームの管理が簡単で、すべての設定がユーザに編集可能な ASCII ファイルを通して行われるので、FreeBSD をインストール済のマシンから、設定ファイルをすぐにコピーすることができます。新しいマシンに sysinstall を使ってゼロから FreeBSD をインストールするのも、同じように手早く簡単に済むので、インストールが終わったときには、他の多くの Unix システムのインストール作業ではできないようなカスタマイズまで完了していることになります (ネットワークの設定やサードパーティのアプリケーションの設定まで一回の作業で済むのです)。
FreeBSD のコミュニティも重要なセールスポイントです。これを書いている間にも、ハンブルグの BSD ユーザグループから、 5 人がプログラマとシステムマネージャとして我々に参加しました。もしこれまでに優秀なスタッフを得ようとしたことがある人なら、彼らの真価を想像することができるでしょう。そして FreeBSD のメーリングリストは、専門的なコンピューティングの多分野に渡る得がたい情報の源です。
もちろん、FreeBSD には問題も存在します。もっとも大きな問題は信頼できる PC のハードウェアを手にいれるのが難しいことです。1991 年に PC Unix を使い始めたとき、私はシチュエーションが悪いと思いました。マルチバス、人力の I/O アドレス管理、熱問題、等々です。驚くなかれ、事態はますます悪くなりました。キャッシュできる領域が 64 しかないマザーボード、パリティの無いメモリ、もっとひどい、パリティをサポートしないマザーボード、壊れた PCI カード、質の悪いケース、壊れた電源やそのお仲間。そんなこんなでスタッフは手一杯になってしまい、とても仕事になりませんでした。PC ディーラーの言い訳は言うまでもないでしょう。
GUI 好きのユーザを抱える我々にとっては、大きなベンダのワークステーションでは手に入る商業ソフトウェア (まあ、MS-Windows のアプリケーションと比べたら、価格に見合うだけの価値があるのかどうかよくわかりませんけど) が無いのも困りものです。
我々自身のプログラミング能力も FreeBSD のサブシステムのすばらしいコードを読むことで向上しました。ここには他の OS をインストールしたマシンも生き残ってはいますが、我々は FreeBSD に非常に満足しています。FreeBSD の使用経験とソースに関する知識が時とともに増すにつれ、ここでの FreeBSD のポジションは強くなる一方です。あなたも FreeBSD に興味を持って、まず小さなビジネスやリサーチのプロジェクトで FreeBSD を使ってくれることを願っています!