入出力アダプタ・ライト・キャッシュを使ってジャーナルの性能を劇的に向上させる
ジャーナル性能の向上
クエリーを高速化する手段として読み込みキャッシュを使用することの利点については多くの人が認識していますし、その効果は本当に目を見張るほどです。これに比べて、ライト・キャッシュもIBM iのジャーナル性能にかなりの効果をもたらすということを知っている人は少ないようです。しかし、ライト・キャッシュはジャーナルで保護されたデータベース・ファイルを更新する頻度の高いアプリケーションの性能を向上させる驚異的なツールとなりえます。
私が初めてハードウェア・ライト・キャッシュを知ったのは、毎年開催されるCOMMONコンファレンスであるセッションに出席した時でした。そのセッションは、ミネソタ州ロチェスター市にあるIBMの研究所に勤務するハードウェア・エンジニアによるセッションでした。そのエンジニアは広い意味で(つまりシステム全体における)ハードウェア・ライト・キャッシュについて説明していましたが、私はジャーナルによって起動されたディスク書き出しにハードウェア・ライト・キャッシュがどのような効果をもたらすのかに興味がありました。
その話題にあまりに心を捕らえられてしまったので、翌週ロチェスター市の研究所に戻った時にそのエンジニアを探してランチを一緒に食べ、ジャーナル機能を開発しているチームの週次ミーティングに来ていただいて話していただいた。ジャーナル保護をかなり使用しているようなIBM iマシン上に十分な量のライト・キャッシュをインストールして設定することでジャーナル・ユーザーに笑顔をもたらすのではないかと強く感じその場を立ち去ったのですが、やはりそれが正しかったのです。十分な量のライト・キャッシュを設定することは、ジャーナルの性能を劇的に向上させるために必要な特効薬となることが多いのです。
なぜライト・キャッシュが重要なのか
ジャーナル・サポートを頻繁に使用している部門では、ライト・キャッシュがもっとも影響力のありかつ有益なハードウェア投資となりえます。より高速なCPUに投資するよりも効果がはっきりと見て取れ、主記憶を追加するよりももっと効果的なのです。その一方、ライト・キャッシュが少なすぎるとせっかくの高いジャーナル性能を阻害することになりえます。
入出力アダプタ内にあるライト・キャッシュは、スピード・マッチング・バッファの役目を果たし、ジャーナル・サポートで発生することがよく知られている一時的な大量のディスク書き込み処理を吸収してくれます。(十分な量の)ライト・キャッシュを設定すると、一般的にはアプリケーションは、データベースの行を追加したり削除したり変更したりする際の待ちが少なくなります。これは、生成されるジャーナル・エントリのイメージを主記憶から入出力アダプタ・ライト・キャッシュに移動する方が、ディスクの回転を待つより通常はずっと速い(最大で10倍程度)からです。事実上、十分な量のライト・キャッシュがあるとディスクの回転が速くなったように感じるのです。
オペレーティング・システムをだます
IBMのエンジニアとの最初のランチでの会話の中で、私はライト・キャッシュを設定することが特にジャーナルを頻繁に使用するアプリケーションにおいてどれくらい有益なのか実験して調べてみたいと話しました。そしてそのような実験をするのに最も簡単な方法を尋ねました。そのエンジニアは身を乗り出していたずらっぽくニヤリと笑ってこう言いました。「そうですね、お宅のマシン・ルームにお邪魔してバッテリーを無効にしてしまいましょうか。」私は何のことかわからなくて「バッテリーって?」と聞きました。彼が言おうとしていたのはOSの他の部分をだまそうということだとわかりました。もちろん私は好奇心をそそられました。
彼の説明によれば、OSの残りの部分をハードウェア・ライト・キャッシュのレポートでだますことができるというのです。つまり、OSの残りの部分が「これを今ディスクに書き込みなさい」と命令し、主記憶と最終的に書き込まれるディスク面の間に十分な量の入出力アダプタ・ライト・キャッシュがあれば、関係するOS部分はディスクへの書き込みが記録時間内で完了したと思い込みます。ライト・キャッシュが設定されているマシン上では、主記憶を離れたイメージは実際にはまだディスク表面にまで到達していないのが一般的です。そうではなくてイメージは単にキャッシュされて少しずつディスクに出力されるのを待っているにすぎないのです。(ライト・キャッシュがどのように動作するのかについての簡単な説明は、ページ下の補足「ライト・キャッシュを例えると」を参照ください。)
このキャッシングの動作の結果、そして主記憶のイメージを安全で永続的な場所に移すことに依存した(ジャーナル・サポート等といった)OSの大部分を再設計したり書き直したりする必要がないことを確かめるために、OSの最も低レベルのレイヤーはハードウェア・エンジニアと協力して、OSはバッテリーで保護されたライト・キャッシュに到達することはディスク表面に到達することと同じくらい信頼できるのであるという契約を結んだのです。エンジニアとOSの設計者は、入出力アダプタ・ライト・キャッシュを冗長化し、バッテリー駆動とすることで入出力アダプタ・キャッシュに到達したジャーナル・イメージがまるでディスク表面にすでに書き出されたかのように存続しているということを確実にするという、この巧妙なごまかしを実現したわけです。このタスクを達成するのにOS設計者は同僚の助けを必要としたのです。すなわちマシンのIPL時に最初のきっかけとなるOS部分を微調整したのです。
したがって低レベルのマイクロコードの設計者たちが、IPLシーケンスの初期に実行される処理ステップに手を入れてこの動作が完了することを確実にしたのです。このテクニックがうまく動作するためには、IPLの実行中にOSの残りの部分がディスクを見に行く前に、バッテリー駆動のライト・キャッシュ中の残存コンテンツを適切なディスク上の宛先に書き出しておかなければなりません。その時点までにはOSの残りの部分(アプリケーションとジャーナルも)は対応するオブジェクト(たとえばデータベース・ファイル、ジャーナル・レシーバなど)が見えていて、残存していたコンテンツは無事ディスク上の適切な箇所に存在していることになります。
実際は、ライト・キャッシュに到達したものが確かに永続的なものになるということについて、ハードウェア開発者も低レベルの記憶管理用マイクロコードの開発者も約束できる場合に限って、ディスクに書き込まれるコンテンツを入出力アダプタ・ライト・キャッシュに委ねる必要があるという「契約」を両者が締結したのです。例のエンジニアがにやりと笑った理由はその契約を反古にする方法を知っているからではないかと感じたのです。この契約の条件の一部として、バッテリー駆動のライト・キャッシュの状態は毎回のIPL時にチェックされるというものがあります。万が一バッテリーが正常に動作しない状態であると、この契約自体が危機にさらされ、ライト・キャッシュ動作が無効になります。つまり、ディスクに書き込まれるコンテンツは入出力アダプタ・キャッシュ内のステージング領域を使用することができず、どれだけディスク書き込みやアプリケーションの性能を低下させることになろうとも、直接ディスクに書き込まれます。一言で言えば性能よりも永続性が優先されるのです。
最初の実験
そのエンジニアはIPLを起動し直すことを含めた2回の性能測定実験をするように薦めました。最初の性能測定実験ではライト・キャッシュにその役目を果たさせます。次にマシンをシャットダウンすると、エンジニアがマシン・ルームに入ってサーバーのカバーを開け、ライト・キャッシュ用のバッテリーを外して再度IPLを起動するように私に言いました。IPLのシーケンスを実行中にOSはバッテリーが起動していないことを検知するので、以後の性能測定実験はライト・キャッシュの恩恵を一切受けずに行われることになります。したがってライト・キャッシュを使用する場合と使用しない場合の2回の性能測定実験の結果を比較することになります。
測定用に使用したバッチジョブに対して、ライト・キャッシュを有効にした場合の処理時間はおよそ90パーセント少なくなりました。これは速度の遅いディスク書き込みやそれに付随するディスクの回転を待つ時間何もせずに待っていることがないからです。その代わりに、ジャーナルの書きだしはディスクの回転が10倍近く高速になったかのように処理されます。
今回の測定結果は確かに目を見張るものがありますが、その測定結果を意味あるものにするためには、1回目の性能測定実験が実際にライト・キャッシュを常に使用していたことを証明する必要がありました。つまり、キャッシュのオーバーランがほとんど起こっておらずライト・キャッシュの閾値を越えることが定常的ではなかったということを確認する必要があったのです。
深く掘り下げる
私が探している入出力アダプタ･ライト･キャッシュの情報を見つけるのに、IBM Performance Tools for i5/OSを使用しました。各測定において収集フェーズを有効にし、その後にデータを削減しました。
収集フェーズは次のコマンドで起動しました。
GO PERFORM
次に、性能データを収集するオプション(デフォルトで15分の収集間隔)を選択し、性能データ収集開始のオプションを選択しました。
デフォルトの収集間隔は15分なので、アプリケーションがバックグラウンドで実行される間、十分な収集時間をとる必要があります。当たり前のことですが、一日のうちで新しいジャーナル･エントリの生成が最も多くなると思われる時間帯にこの15分間隔が入るようにスケジュールしなければなりません。
ディスクの動作に関連する収集データを抽出するには、次のコマンドを実行して収集された性能データを問い合わせ可能なファイルにダンプさせます。
CRTPFRDTA FROMMGTCOL(*ACTIVE) TOLIB(Sample1) CGY(*DISK)
データ収集フェーズを終了させるには次のコマンドを実行します。
GO PERFORM
次に、性能データの収集オプションを選択し、さらに性能データ収集終了のオプションを選択します。
収集したデータを分析するには、次のようなクエリーを使用してディスクへの書き出しの総回数に比較していわゆる「高速な」書き出しを分離します。
SELECT 100 * SUM(DSCCFW) / SUM(DSWRTS) FastWrtPrfcnt from Sample1/QAPMDISK where DSASP=1
個別のプライベート･ユーザーの補助記憶域プール(ASP: Auxiliary Storage Pool)内にジャーナル･レシーバを分離した場合は、そのASPを上記のコマンドのDSASP where節で指定する必要があります。
どれだけあれば十分か
私は例のIBMのエンジニアに尋ねてみました。入出力アダプタ・ライト・キャッシュが十分あると言えるには「速い」というカテゴリに分類されるディスク書き込みがどれくらいの割合あればよいのですか、と。そのエンジニアは、「遅い」ディスク書き込みは「早い」ディスク書き込みの10倍程度の時間がかかるので、書き込みの1パーセント以上が「遅い」書き込みになると錨をおろした船のようになる、と説明してくれました。つまり、少なくとも99パーセントのディスク書き込みが「速い」に分類されるものでなければならないのです。それ以下になるとおそらくライト・キャッシュを追加しなければならないでしょう。
ライト・キャッシュのサイズはさまざまなので、十分な量のハードウェア・ライト・キャッシュがあることが重要です。特に、時々大量のアクティビティがあるような本格的なジャーナル・ユーザーであればなおさらです。ディスク書き込みの99パーセント以上が「速い」というカテゴリにならないのであれば、ジョブの実行速度はジャーナル書き込みによっておそらく低下することになるでしょう。
その解決方法は、たとえ各入出力アダプタに最大数のディスク装置を設置することができなくなったとしてもライト・キャッシュを追加することです。ライト・キャッシュを追加することで各ディスク装置にかなりのサイズのライト・キャッシュが割り当てられることになります。この方法の詳細についてはIBMの記事「ジャーナリング － 十分な量のライト・キャッシュを設定する」を参照ください。
入出力ライト・キャッシュは、ジャーナル・ユーザーであるあなたを苦しめるものに対する魔法の薬のようなものです。薬棚にじゅうぶんな量の在庫があるようにしておいてください。
補足: ライト・キャッシュを例えると
同僚のハードウェア・エンジニアと入出力アダプタ・ライト・キャッシュの恩恵について話をしている時に、そのエンジニアが公式なプレゼンテーションで話した技術的な詳細は忘れて、私の母親に説明するかのようにライト・キャッシュの概念を簡単に言うとどういうことなのか、と尋ねました。そのエンジニアの答えは、ライト・キャッシュとはじょうろのようなものだというものでした。
OSが新しいジャーナル・イメージをディスク上に書き出していると思っている時、実際にはジャーナル・イメージをステージング領域に送信しているのです。このステージング領域は穴の開いているじょうろのようなものです。このじょうろには最大容量があるのでジャーナルが上の縁まで入ると溢れますが、底にも穴が開いていますので、貯まったジャーナルが底から漏れるにつれてさらにジャーナル・エントリを上から流し込むことができます。ジャーナル・アクティビティは貯まっているうちの最新のジャーナルを、ディスク上にあるジャーナル・レシーバに急いで出力しようとしますので、それに相当する主記憶のページ・イメージがじょうろを通過していきます。新しいエントリがジャーナルに流される速度は、アプリケーションの組み合わせにより速くなったり遅くなったりしますが、ディスクに書き込まれるイメージが少しずつ流れ出てくる速度は一定で、ポタリ、ポタリ、ポタリと開いている穴から出てきます。入出力アダプタ・ライト・キャッシュの総容量が十分であると仮定すると、ピーク時の流入速度はライト・キャッシュをほんの少しだけ増やすにすぎず、ピークが過ぎれば吸収した流入分を少しずつ出すことができます。しかしピーク時の到着速度が容量を超える寸前になると、庭師が来てじょうろを手で空にするまで待つように告げます。
この例えを続けると、ジャーナル・エントリの到着速度が定期的に増大する場合(おそらくバッチ・ジョブの実行中)は、適切にサイズを分類してもっと大きいじょうろを用意すればよいことになります。入出力アダプタ・ライト・キャッシュには最大容量があります。その最大容量を決して上回ることのない流入速度を維持することができれば、大げさなアクションは必要ありませんし、ポタリ、ポタリ、ポタリという安定した流出により溢れは生じません。したがって、じょうろのサイズが十分であれば、じょうろの上の縁まで一杯になることはなく新しいジャーナル・エントリが到着しても妨げになりません。しかしもしジャーナル・アクティビティが爆発的に到着してじょうろの容量を超えると、顕著な性能低下が起こります。この低下は前のライト・キャッシュ・コンテンツがディスクに移動して新しく到着したジャーナルのために場所を空けるのを待たされることによるものです。
実際、溢れだすのを防ぐためにじょうろは閾値があるかのように動作します。ディスクに書き出されていない主記憶イメージの量がこの閾値を下回っている限り、新しいイメージを高速に受け入れることができて性能は高く保たれます。しかし一旦この閾値を上回ると動作速度の低下が起こります。ですからこの閾値以下で運用するということが目的となるのは言うまでもありません。
