DB2/400 の SMP オプション

DB2/400 の SMP オプションについて、いろいろ調べてみたことの覚え書きです。

SMP 対応とは

SMP 対応とはどういうことか、というと、データベース・エンジン/オプティマイザーに並列処理を考慮したアクセス・メソッドが追加される、ということになります。タスク(CQE)/スレッド(SQE) 単位での並列化を、データベースを処理する際の新しいオプションとして考慮できるようになる、ということですね。

その追加のアクセス・メソッドを導入するために、OS/400 の有償フィーチャーである「DB2 マルチ・プロセス」というライセンス・プログラムを導入する必要があるわけです。

SMP 対応の前提

他のデータベースでよくあるように、SMP オプションを使用するためにはテーブルがパーティション化されていないといけない、とかそういったことはありません。
通常の PF/テーブルでちゃんと SMP オプションは使用できます。

また、先に記述したように"タスク(CQE)/スレッド(SQE) 単位での並列化を、データベースを処理する際の新しいオプションとして考慮"するわけですから、必ずしもプロセッサーが複数ある必要もないことになります。
データベースの並列処理オプションを追加する、ということですが、その並列化の単位は CQE の場合はタスク、SQE の場合はスレッドです。タスクもスレッドも、OS/400 がマルチタスクの OS である以上並列処理はされているわけです。

また、オプティマイザーに並列処理を行うというストラテジーを加える、というのがこのソフトウェアの機能になります。
つまり、原則として SQL インターフェイスによる処理について適用され、RPG によるデータベース処理 (レコード処理) には適用されません。こうしたことも、今後データベースの処理については SQL に移行していった方がいいだろう、ということの理由のひとつですね。

並列処理、というのは具体的に言うと複数のタスクないしスレッドに分割して同時に稼動させるということです。
時間のかかる RPG のバッチプログラムがあったとしても、それは 1ジョブであり、1スレッドでしか実行できないので処理を並列化することができません。

もともと OS/400 はデータベースオブジェクトに対して I/O の並列処理などは行っています。
オプティマイザーにこの I/O 単位の並列処理を考慮させる/勘定に入れる、という設定もあり、この設定だけで並列化を行うためには「DB2 マルチ・プロセス」を導入する必要はありません。

データベースオブジェクトの I/O 単位での並列処理はもともと OS/400 の機能で行われています。
DB2/400 の他データベースとの大きな違いはデータベースエンジンが OS と一体化している、ということですが、そのため OS が行うファイルシステム上でのアクセスの最適化をデータベースオブジェクトの特性を見ながら行うことができるようになっています。
通常の OS にとってはファイルシステム上のファイルは単なるフラットファイルに過ぎないわけですが、OS/400 にとってはテーブルだったりビューだったりインデックスだったするわけです。それぞれの内容、特性を考慮して OS がアクセスを制御する、ということは他のデータベースエンジンにとって、とってもやりたいことなのですが、とてもできないことなのだと言っていいでしょう。

考慮点

並列化しても効果のない処理を CPU に空きのある状態で実行した時

シングルスレッドで CPU 依存の処理は並列化しても結果はほとんど変わりません。
たとえば複数の選択データを後で UNION するような場合は別々の処理を並列で走らせて後でまとめることで、並列処理の効果を得ることができます。
一つのタスク/スレッドでそれなりの時間をかけなければ完了できないような処理の場合、並列でトライしたけれど処理時間はあまり変わらない、ということが起こり得ます。
この場合は、CPU ばかり (結局それぞれの CPU が同じような処理を行うから) が消費され、結局処理時間はほとんど変わらなかったということもあり得ます。つまり並列処理をトライしてみたが、CPU 依存の処理だったために結果の時間は変わらなかった、という状態になります。
ただし、これは CPU が余っているような時に起きる挙動です。システムが空いているので、後で触れる "*MAX" というオプションと同様の状態になっているために起きる事象ですので、「ちょっと並列化のテストを行ってみよう」などと、占有状態にしてテストすると「なんじゃこりゃ」ってことになりかねません。ご注意を。
逆に言えば、(CPU を占有するといった) 特殊な環境下でのテストでそういった事象が出たからといって、折角の機能を使用しないというのも馬鹿げたことのような気もしますね。本来だったらもっと速く実行できる処理をわざわざ遅くしているわけですから ......

SMP が適用できる処理

Query Dispatcher の紹介のところでも、V5R2 では SI07650 が適用されているかいないかによって SQE が SMP オプションを考慮するかどうかが異なってくることが書かれています。
アクセスプランの紹介で例に挙げられているアクセス・プランの内容にも、「アクセス・プランがシステムに導入された DB2 UDB 対称マルチプロセスによって保管された。」というメッセージがあります。つまり、SMP 対応によって追加されたアクセス・メソッドを考慮した、ということがここでわかるわけですね。

SMP オプションは以下の処理で使用を考慮されます。

(*1) SELECT/JOIN 時の Index Scan /Probe、SELECT 時の Table Scan /Probe (bitmap /RRN list)、GROUP/JOIN 時の Hash に使用される (V5R3 時点)

SMP オプションは以下の処理で使用されません。

QDBSRVxx サーバージョブ

QDBSRVxx というデータベースサーバージョブについては、通常は以下のように 05 まで動いていると思いますが、追加のプロセッサーが存在し、さらに SMP オプションが有効になっている場合は 06 以上が稼動するようです。

SMP オプションの設定

基本的に SMP オプションはシステム値 QQRYDEGREE で設定します。

以下のように *OPTIMIZE という指定が基本になるでしょう。
*IO という指定をすると、I/O の並列化を考慮するようになります。これには「DB2 マルチ・プロセス」の導入は必要ありません。
*OPTIMIZE と指定すると、前述したようなタスク(CQE)/スレッド(SQE) 単位での並列化を、システムが最適化して考慮するようになります。

*IO という指定がありますが、これは I/O の並列処理をオプティマイザーに考慮させるようにするもので、DB2 マルチ・プロセスを導入する必要はありません。
ですので、基本的に少なくとも *IO を指定しておいて損はないでしょう。(システム構成にはよりますが)

*MAX というのは、空いていれば空いているだけ使う、という超攻撃的なプランです。もう占有で専用に使えるような場合には指定可能ですが、通常何かの処理が動いているような状況では指定できませんね。

並列度合いの決定

*MAX 以外の場合、並列度合いはメモリーのフェア・シェアを使って決められます。
CQE と SQE とで計算方法が異なりますが、だいたいそれぞれ以下のようになっています。

CQE では

メモリー・プール・サイズ/MAXACT値

SQE では

メモリー・プール・サイズ/(MAXACT値 or [5 or x の大きい方]の小さい方) → MIN(MAXACT, MAX(x, 5)
x は *FIXED の場合はユニークなユーザー数・*CALC の場合は 15分単位での平均ユーザー数

というように計算された値をフェア・シェアと呼び、これをもとにシステムが並列度合いを決める、というわけです。

並列処理の確認

個々のデータベース処理でこの並列化が考慮されているかどうかは、Visual Explain での「並行度数の設定」で確認することができます。
あと、確認したわけではないのでなんともいえませんが、↑が二つになったりするらしいです。

また、「SMP 並行の情報」でも確認できます。

オプティマイザーが考慮するアクセス・メソッドは、繰り返しになりますが以下のようなものです。
つまり、以下のものしか V5R3 時点では上に挙げた Visual Explain の絵には並列化されて出てこないというわけですね。

[Top Pageに戻る]

Ads by TOK2