ジョン・ダベンポート著

皆さんは論理パーティショニングがビジネスにどんな恩恵をもたらすかについてはすでにご存知でしょう。しかしLPARを自社の環境に実現したならば、次のステップに移るべきです。すなわち、iSeriesの高度なアーキテクチャである同時マルチスレッド処理(SMT)、(キャップ、アンキャップ)共有プロセッサ、そして中でも特に重要な仮想プロセッサ(VP)を適切に割り当てて最適なパフォーマンスを得る方法を理解するステップに進んでください。LPARの秘伝のアーキテクチャ概念を習得して自社のシステムの効率をさらに上のレベルに向上させたいのであれば、本稿を是非お読みください。

同時マルチスレッド処理
OS/400の初期のバージョンでは、タスク・ディスパッチ・キュー上の2つのスレッドが実行可能状態になっている場合、図1に示す例のように、それぞれのスレッドは連続的にディスパッチされて実行されます。後のバージョンでIBMはQPRCMLTTSKというシステム値を実装し、2つのスレッドを並行して実行できるようにしました(ただし、このシステム値を変更して有効にするにはIPLが必要となります)。現在の世代であるi5プロセッサ以前では、IBMはマルチスレッド処理をマルチ･ディスパッチ(図1の2番目の例)までに制限していました。この制限下では、スレッドは依然として並行ではなく連続的に実行されます。今日のi5ファミリのサーバー･シリーズ(およびV5R3)では、図1の3番目の例に示すように、QPRC MLTTSK 値を有効にして2つのスレッドを同時にディスパッチして実行させることができます。この機能を同時マルチスレッド処理と呼びます。

SMTが便利なのは、2つのスレッドが同時に実行されていると各々のスレッドの完了時間は多少長くなりますが、両方のスレッドが完了するまでの合計時間を短くできるということです。この概念を図2に示しています。最初の例(SMTがオフになっている)では2つのスレッドが連続的に実行され、完了までに合計22サイクルかかっています。SMTをオンにすると、各スレッドが完了する時間は多少長くなっていますが、両スレッドが完了するまでに必要な時間が約40％短くなっています。

「確かに興味深い機能ですが、LPARと関係があるのですか」という疑問を持つかもしれません。答えは「まったく関係ありません」でもあり「大いに関係があります」でもあります。本稿をお読みいただければこの意味がお分かりいただけますので、お付き合いください。

基本概念
共有プロセッサがどのように動作するのかを理解するために、まずいくつか基本的な概念を理解していただく必要があります。

仮想プロセッサ(VP) 共有プロセッサ・パーティションを作成する際に設定する必要のあるパラメータの1つが仮想プロセッサです。この値はパーティションのオペレーティング・システムが実際に所有していると思っているプロセッサの数を表しています。たとえばVPが1つであると指示した場合、そのパーティションのオペレーティング・システムは自分が1つのプロセッサ上で実行されているとみなします。2を指定すると、OSは2ウェイ・プロセッサを検知する、といった具合です。VPの数は常に自然数となります。

共有処理単位 共有プロセッサ・パーティションは、そのパーティションに複数の処理単位(PU)を割り当てることで作成します。たとえば、1.00 PUは1つの専用プロセッサの処理容量とほぼ等価で、2.00 PUは2つのプロセッサ、0.5処理単位は全プロセッサ(パーティションをどのように構成しているかに依存)の約半分の容量となります。仮想プロセッサをオーバーコミットすると、1,500 CPWが表す馬力を必ずしも得ることができません。

共有プロセッサ・プール プロセッサが共有プロセッサ・プールに入っていないと、その処理容量を複数の論理パーティションで共有することができません(i5サーバではこれがデフォルトになりました)。共有プロセッサ・パーティションはすべて共有プール中のすべてのプロセッサ上で実行されます。あるパーティションのスレッドをどのプロセッサ上で実行させるかというコントロールはできませんし、そんなことはしたくないでしょう。ただし、前述の仮想プロセッサ・パラメータを使用することで、プールされているプロセッサのうちのいくつのプロセッサでパーティションがスレッドを並行して実行できるのかをコントロールすることはできます。

ディスパッチ・ウィンドウ 現在、i5のプロセッサ時間は10ミリ秒(ms)のタイムスライスで割り当てられており、これをディスパッチ・ウィンドウと呼びます。つまり、各プロセッサには(壁掛け時計の)物理的な10ミリ秒ごとに10ミリ秒のプロセッサ時間が与えられることになります。各ディスパッチ・ウィンドウの終わりでは、プロセッサがあたかも「リフレッシュ」して10ミリ秒ごとに再起動しているかのように見えます。

たとえば、4つのプロセッサが共有プールにあるeServer上でi5/OSシステムが実行されている場合、物理的な10秒ごとに40ミリ秒の処理時間が与えられていることになります。ここが重要なところです。たとえば1.8 PUを1つのパーティションに割り当てたとき、そのパーティションに対して結果的には(40ミリ秒のプールの中から)18ミリ秒の処理時間を割り当てることになるからです。

図3は、その18ミリ秒が異なるVPにどのように割り当てられるかを示したものです。パーティションをどのように構成するかによって、実際のプロセッサの2つ、3つ、あるいは4つを同時に使用する可能性があるわけです。このパーティションに対しては少なくとも2つ(デフォルト値)のVPを与える必要があるでしょう。というのは、各VPが10ミリ秒の処理時間(すなわち、1.8 PUは18ミリ秒の処理時間)を表しているからです。ただし、VPには2から18までの間のいくつをこのパーティションに割り当ててもかまいません。

「プールに4つのプロセッサしかないのであれば、18のVPをどのように使用するのか」とお尋ねになるかもしれません。良い質問です。このパーティションには18 VPまで与えることができます。なぜなら1.8の10倍だからです。そして、それだけの数のVPをこのパーティションに与えることができても、そうすべきか否かはまったく別の問題になります。(これについては後述します。)

キャップ・パーティションとアンキャップ・パーティション 「キャップ」、「アンキャップ」という用語はi5およびp5 eServerの共有プロセッサ・パーティションだけに使用できる用語です。キャップ・パーティションは簡単です。今回紹介している例でいえば、1.8 PUのパーティションを作成したので、18ミリ秒の処理時間と等しくなります。このパーティションに割り当てたVPの数にかかわらず、18ミリ秒以上のプロセッサ時間は使用できません。このパーティションがこの18ミリ秒をすべて使用すれば、その「壁時計の」10ミリ秒間はこのパーティションが100%ビジー状態になります。

アンキャップ・パーティションはちょっと理解するのが厄介です。本質的には、アンキャップ・パーティションが保証した処理時間以上のミリ秒を使用する可能性を持っていますが、それは余分なミリ秒が利用可能な場合に限っての話です。別の言い方をすると、他の共有プロセッサ・パーティションが現在使用していないミリ秒がプール中にある場合に限っての話ということになります。今回紹介している例では、1.8 PUのパーティションは少なくとも18秒の処理時間が保証されていますが、このパーティションがどのように構成されているのか、未使用のミリ秒があるのかによっては、プールのプロセッサ時間40ミリ秒をすべて使用する可能性があるということです。このパーティションが40ミリ秒すべてを使用した場合、その物理的な10ミリ秒間にこのパーティションは222％ (40/18)ビジーになります。この後すぐに説明しますが、仮想プロセッサ・パラメータがこの鍵を握ります。

パズルを組み立てる
さて、4ウェイのi5を複数の共有プロセッサ・パーティションに分割して、これらの一見バラバラのピースを一つにまとめてみましょう。本稿の残りの部分では、システム値QPRCMLTTSK がオンになっていると仮定します。最適なパフォーマンスを得るにはおそらくオンになっている必要があるからです。

キャップ・パーティションの作成 まずキャップ・パーティションを作成します。必要な処理単位パラメータを使用して、作成したパーティションに0.5 PU (5ミリ秒)を割り当てます(図4)。対応する必要な仮想プロセッサ・パラメータについては、デフォルト値である1つのVPのままにしておきます。こうしてもパーティションがプール中の1つのプロセッサしか使えないという制限にはなりません。パーティションが一時期には1つのプロセッサ上のスレッドしか実行できないというだけです。このパーティションは、私が割り当てたVPの数には関係なく、最大で5ミリ秒の処理時間を得ることができます。つまり、2つのスレッドがディスパッチされた場合、その2つのスレッドはおそらくこの5ミリ秒をすべて使用し、実行を完了します。しかしたとえば、さらに4つの仮想プロセッサを追加して(合計5つのVP)容量を拡大すると、パーティションのOSは最大で10個のスレッドをディスパッチできるようになります。ただしここで、2つのスレッドが5ミリ秒の処理時間を得るのではなく、各スレッドのペアがたった1ミリ秒しか与えられないことになります(5ミリ秒／5つのスレッドのペア=スレッドのペアあたり1ミリ秒)。

iSeriesのLPARでは0.1 PU以下のPUを持つパーティションを作成することはできません。スレッドが何かを処理するのに必要な時間の最小単位が1ミリ秒だからです。スレッドをプロセッサ上で実行するには、まずそのスレッドのジョブ・ストリームとデータをプロセッサのキャッシュに読み込まなければなりません。スレッドのデータをキャッシュに読み込むのに1ミリ秒(0.1 PU)の大半が費やされると、そのスレッドがこのプロセッサ上で何か処理を完了させる時間がほとんどなくなります。スレッドが処理を完了させるのに時間が足りなくなるのであれば、もう一度ディスパッチされておそらく他のプール・プロセッサ上で実行されることになるでしょう。これにより、キャッシュを再読み込みしなければならなくなります。このスレッドが同じプロセッサ上で再実行されたとしても、他のジョブがデータをオーバーレイしているので、もう一度ジョブ・ストリームとデータを読み込まなければなりません。パーティションのスレッドは、同じパーティション中の他のスレッドと競合しているだけでなく、すべての共有プロセッサ・パーティションのスレッドとも競合している、ということを覚えておいてください。

キャップ・パーティションの設定は簡単です。ハードウェア管理コンソール(HMC: Hardware Management Console)が最も近い自然数に丸めてくれるので、そのままにしておきます。最小値よりも大きなVPを追加すると、より多くのスレッドがディスパッチされ、ディスパッチされたウィンドウ１つあたりが受け取る処理時間が少なくなる可能性があります。最小数のVPよりも多くのVPを設定するというやり方は、スレッドが再ディスパッチされることなくその処理を完了するのに十分な時間を与えられる可能性を小さくします。

アンキャップ・パーティションの作成 アンキャップ・パーティションの設定は若干複雑です。VPは1つのパーティションが同時に使用できるプロセッサの数であり、オペレーティング・システムが「所有している」とみなしているプロセッサの数である、ということを覚えておいてください。またVPは、1つのパーティションが物理的な10ミリ秒のサイクル時間に使用できるミリ秒の上限でもあります。0.8 PUで1つのVP(デフォルト)のアンキャップ・パーティションを作成した場合、そのパーティションは最大で125%までビジーになり得ます。8ミリ秒は確保されていますが、10ミリ秒使用する可能性もあります(10/8=1.25または125%)。2つのVPを使用する場合(共有プロセッサ・プール中に少なくとも2つのプロセッサがあるという仮定で)、このパーティションは20ミリ秒すべてを使用し、250% (20/8)までビジーになる可能性があります。これがアンキャップという意味です。つまり、適切に設定されたパーティションはプール中のすべてのプロセッサをおそらく常に使用することができます。もちろん、実際にそうなるにはさまざまな条件(たとえば、ディスパッチ待ちのスレッドが十分あり、ディスクI/Oが発生せず、実行待ちのアプリケーションがなく、余分なミリ秒が利用可能であるなど)が揃う必要があります。

「仮想プロセッサが多ければ、アンキャップ・パーティション内では余裕があるのでは」とおっしゃるかもしれません。必ずしもそうではありません。4つのプロセッサを装備したi5上に2つのアンキャップ・パーティションが同じ共有プールにある例を図5に示します。右側の(P2)パーティションには必要となる1.5 PUが2つのVPに渡って割り当てられています。左側(P1)のパーティションには必要となる0.5 PUが5つのVPに渡って割り当てられています。10の規則を覚えていますか。対応する、必要となる最小および最大のVP数は物理的な(処理単位)数の10倍までとなります。共有プールにプロセッサが4つしかなくてもHMCではこれが可能です。

つまり(プール中の4.00 PUのうち)2.00 PUしか使用していないのですが、物理的な4つのプロセッサ上で同時に実行できる以上のスレッドをすでにディスパッチしてしまっているのです。P1パーティションのオペレーティング・システムはプロセッサを５つ装備していると思っており、P2パーティションは2つ持っていると思っています。この2つのパーティション間で、14個のスレッドをディスパッチすることが可能です。各々のスレッドは1つのディスパッチ・ウィンドウあたり、より少ない実行時間を与えられる可能性があります。キャッシュの読み込みや再読み込みは実行時間の大半を占める可能性があります。プロセッサを使用できる時間が少なくなるということは、そのスレッドが完了せず再ディスパッチされる可能性が高くなります。スレッドが再ディスパッチされると別のプロセッサ上で実行される可能性もあり、その場合キャッシュを再読み込みする必要があります(前回と同じプロセッサ上で実行されたとしても再読み込みが必要となる可能性もありますが)。残りの2.00処理単位にパーティションを追加作成するとスループットを低下させてしまう可能性があります。

アンキャップ・パーティションのフィールド・ガイド
うっかりしているとLPARはすぐにわからなくなってしまいます。特に、仮想プロセッサを使用して複数のパーティションが最大限の効率を得られるように構成しようとするとなおさらです。システムをチェックする際に覚えておくと便利なヒントをいくつかご紹介します。

・ 必要なVP数を共有プール内のプロセッサ数より多くしたり、VPの最大数を実際に搭載されているプロセッサの数よりも大きくしたりしても構わないなどという場合は決してありません。

・ 0.5 PUとは、実際には1つのプロセッサのCPWの半分ではないかもしれないということを理解しておいてください。特に、必要なVPの数が大きすぎる場合には注意が必要です。たとえば2つのプール･プロセッサしかない管理システムに5つのVPを設定するといった場合です。

・ 必要とする処理単位が自然数に近い場合は専用のプロセッサを使用することを検討してください。ただし、専用プロセッサ・パーティションは共有プール処理時間を超えて使用することはできず、他のパーティションはその処理資源を超えて使用することはできない、ということを理解しておいてください。

・ 常に100%を超えた状態で実行されているパーティションは、(実際に)必要なPUに限っていえば少なめです。キャップ共有プロセッサ・パーティションを構成するときは、パーティションが機能できる最小の値に最小PUを設定します。必要なPU数はキャパシティ・プランニングで決定した値に設定します。最大PUはサーバー上のプロセッサ数に設定します。仮想プロセッサのデフォルト値を変更する必要はありません。

・ アンキャップ共有プロセッサ・パーティションを構成するときも、PUについては上記のアドバイスが有効です。また、PU数が自然数に近くなければ仮想プロセッサについても上記のアドバイスが有効です。パーティションを(もっと)アンキャップにするには、必要なVP数を増やしても構いませんが、その数は共有プールのプロセッサ数を決して超えてはいけません。

・ 集合効果があることを忘れないでください。つまり、必要な仮想プロセッサをそれぞれ4つ備えた4つのパーティションがある場合、4つのオペレーティング・システムが合計で32個のスレッド(4パーティション×4 VP = 16プロセッサ×2スレッド = 32スレッド)をディスパッチする可能性があります。

・ 常に100%以上ビジー状態にあるアンキャップ・パーティションはすべて、現在使用されていない資源(ミリ秒)を使用しているということを理解してください。いずれ、この余分な資源が利用できなくなるかもしれないのです。

・ そうしたアンキャップ・パーティションの1つがCPUループに陥ったらどうなるでしょう。1つのプロセッサを「食べ尽くして」しまいますか。CPU使用率が100%以上にはなるでしょうが、あるパーティションの実行可能状態にあるスレッドで、100%までビジーになっていないスレッドがあれば即座にそのCPUを使い始めます。アンキャップ・パーティションは、保証された量のPUを超えると余分なプロセッサ資源だけを使用します。すべてのパーティションは、保証されたプロセッサ資源を得ることができます。これは他のパーティションが何を実行しているかには依存しません。

最後に、パフォーマンスに関する質問への答えは、場合による、という答えになることがほとんどだということを覚えておいてください。本稿で説明したテクニックは、絶対で例外がないというものではなく、助言に過ぎません。i5 eServer上での完璧なパーティション構成を確実に身に付けるには、ベンチマークを実施するか、さまざまな組み合わせを試してみるかして、どれが一番良いかを見つけることです。ではLPARを楽しんでください。

ジョン・ダベンポート氏はIBMに30年以上にわたって勤務しており、CEディスパッチャからレベル２サポート・ライン担当にいたるまでの経験があります。現在は、アドバイザリ・ソフトウェア・エンジニアとして勤務しています。同氏は、1995年にiSeriesテクノロジ・センターが設立した当初から同センターに所属し、テクニカル・コンファレンスでのLPARについての講義からオンサイトでの実作業までとありとあらゆる業務をこなしてきました。