IBM i のウンチクを語ろう
～ その8：IBM i のウンチクを語ろう ～ 単一レベル記憶-3 ～
皆さん、こんにちは。これまで2回分を費やして、他システムのファイル・システムにまつわるパフォーマンスの課題をいくつかの観点から検討し、単一レベル記憶はそれらに対する解決策として考えられたものであることを述べてきました。マシン・インターフェース（TIMI：Technology Independent Machine Interface = 仮想マシン）上にあって、ディスク領域もメモリであるかのように見せかけながら、両者を単一のメモリ空間として管理する仕組みであるわけですが、今回はその仕組みを探ってみます。
単一のIBM i が保持できるメモリとディスクの記憶域は、合わせて最大264バイトであることは前回述べたとおりです。マシン・インターフェースにおいてこの空間は全てメモリに見えていますので、アクセスするためにアドレスが割り当てられ、全体がページと呼ばれる4KBの大きさのブロックに区切られ管理されています。この空間は見かけ上のものなので、割り当てられているアドレスも仮想的なものです。一方で実際のハードウェアのレベルで見ると、空間はメモリとディスクのそれぞれの領域で構成されており、どちらも同様に4KBのページ単位に区切られています。そしてマシン・インターフェース上に存在する全てのページは、実際のメモリまたはディスク領域上のページに対応付けられています。
単一のファイル（IBM i においては正確にはオブジェクトと呼ばれる）は、通常複数のページで構成されており、マシン・インターフェース上の仮想アドレス空間の中で連続する領域を占有します。ユーザーは、これに対応する実際のページが、メモリとディスクのどちらに存在するのかを特定することはできません。また単一ファイルの複数ページだからといって、必ずしもハードウェアの連続領域にあるとも限りません。仮想アドレス空間上のページとハードウェア上のページの関連付けや、ハードウェア上にあるページのメモリないしディスク領域における配置は、マシン・インターフェースよりも下層にある、マイクロコードに相当するSLIC（System Licensed Internal Code）によって管理されています。
あるユーザーがプログラムを呼び出す状況を想定してみましょう。指定されたライブラリ名・オブジェクト名に基づいて、システムは仮想アドレス空間上のページを特定し、次に対応するハードウェア上のページがメモリ内にあるかどうかを調べます。ここでもし見つからなければ、ページはディスクに存在するものとしてその場所を特定すると、メモリで未使用のページ領域に移動して実行します。移動されたページは可能な限りそのままメモリ内に留まります。ここで別のユーザーが同じプログラムを起動しようとすると、該当ページは既にメモリに読み込まれていますので、ディスクにアクセスすることなく直ちに実行されます。もしこれが他のシステムだった場合、ユーザーが異なればその作業空間は別に確保されなければなりませんので、プログラムは再度ディスクからメモリに移動されます。これは全てのユーザーがシステム資源を共有できるのか、ユーザー別に資源を確保しなければならないのか、の違いです。ディスク・アクセスはメモリの場合と比べて、何万倍もの時間を要するプロセスですので、メモリをあたかもキャッシュとして利用できる単一レベル記憶の仕組みは、パフォーマンス上極めて有利に機能します。
メモリ容量はディスク容量よりも小さいものなので、全てのディスク上のページをメモリに収容することはできず、いずれはメモリ上の空きページ領域を使い果たしてしまう可能性があります。IBM i も例外ではありません。ここでさらに新たなページをメモリに移動する際には、空き領域を確保するために逆方向、すなわち既に存在しているメモリ上のページをディスクに追い出す必要が生じます。どのページを移動対象にするのか、搭載されている複数のディスク・ドライブの中でどれを書出し先にするのか、を決定しなければなりません。
書出しページを決定するのはきわめてシンプルです。最も長時間アクセスされなかったページが選ばれます。これはLRU（Least Recently Used）方式と呼ばれる、ごく一般的に利用されるアルゴリズムです。一方、書出し先の決定にあたって、SLICはシステム稼動中に各ディスクのアクセス状況を常時モニターしており、その統計情報を参照しながら最も利用されていないディスクを選びます。システム使用中にIBM i のディスク使用率が自動的に平準化されるのは、この仕組みによります。例えば容量一杯までデータが書き込まれた10個のディスクで構成されたシステムに、新たに11個目の空のディスクをインストールすると、これは最も利用されていないディスクになるので、全ディスクの負荷が平準されるまでここに数多くのページが移動されてきます。
他のサーバーであれば、データベースの管理を行うことによって、各ディスクにかかる負荷をどのようにして分散するのかを検討する必要があり、専任のデータベース管理者がその作業を行います。ディスク容量の限界が近づいたために空のディスクを追加したら、あらためてファイルの再配置を行わなければなりません。一方IBM i においてはこの作業が自動的に行われるために、専任のデータベース管理者を必要とすることがありません。データベース管理者要らず、というのはシステム運用に要する手間、ひいてはTCO（Total Cost of Ownership： 総所有コスト）削減に大きな効果があります。特に他のサーバーからIBM i に移行してきたユーザーが、日々の運用の違いとして最も強く感じるのはこの点です。IBM i に慣れていないと、何もしない、すなわち手を下す術がない、と考えて不安になってしまうケースもあるそうですが、実態はシステムの自動運転を前提とした設計になっているわけです。
昨今はIBM i システムを構成する際に、ハードディスクとSSDとを混在させるケースも増えてきています。ハードディスクはアクセスされる事の少ない大量データを保管するため、SSDはその高速性を活かして各種の処理を行う対象のデータを保管するため、という具合に使い分けられます。単一レベル記憶はこれらのデバイスとその特性の違いを認識し、自動的に最適なページ書き込みを行います。SLICは常時各ページのアクセス頻度を見張っていて、アクセス頻度の高い「生きている」ページはSSDに、「休眠状態に近い」ページはハードディスクに配置します。そしてSSDはアクセス時の遅延時間が圧倒的に短いので、その容量一杯までページが書き込まれますし、そうなったとしてもパフォーマンス上悪影響が出ることはありません。IBM i の先代のシステム/38登場当初から実装されている単一レベル記憶は、パフォーマンス最適化と運用自動化の観点から、新たなテクノロジーの登場に合わせて進化もしているのです。そして容量あたり単価が高いという印象が根強いSSDですが、実態はディスクの2～3倍程度まで近づいていますし、そのパフォーマンスとIBM i での使い勝手の良さを考慮すると、十分にその投資価値があるはずです。
ここまで単一レベル記憶の仕組みを述べながら、そのメリットを述べてきました。次回はこのテクノロジーにおける懸念点と、IBM i に実装されている解決策について説明する予定です。
