![]() |
![]() |
日本−日本語 | ![]() |
|
|
![]() |
![]() |
HP OpenVMS Alpha: パーティショニングおよび Galaxy ガイド![]() 第3章 OpenVMS アプリケーションに対する NUMA の影響 |
|
![]() |
目次 NUMA (nonuniform memory access) とは,特定の物理メモリ位置へのアクセス時間が, すべての CPU で同じにならないというシステムの属性のことです。 このアーキテクチャの下で高い性能を実現するためには,(100 パーセントとはいかなくても) 一貫して適切なロケーションを確保する必要があります。 オペレーティング・システムは,ハードウェアをリソース・アフィニティ・ドメイン (RAD) のセットとして扱います。 RAD は,共通のアクセス特性を持つ物理リソース (CPU,メモリ,および I/O) のソフトウェア上の分類です。 AlphaServer GS80/160/320 システムでは,RAD はクォド・ビルディング・ブロック (QBB) に対応し,AlphaServer ES47/ES80/GS1280 システムでは,2 プロセッサの CPU ボードに対応します。 CPU は,自分の RAD の中のメモリについては,他の RAD の中のメモリよりも高速にアクセスすることができます。 OpenVMS が 1 つの RAD のリソース上で実行されている場合には,NUMA による影響はなく,ここでの説明は適用されません。 可能性と実現性がある場合,できるだけ 1 つの RAD の中で実行することで NUMA の複雑な影響をなくし,高い性能を引き出すことができます。 NUMA 環境における全体的なシステム性能に関して最も多い質問は, “すべてに対して一様” と “少数に対して最適化” のどちらを選ぶべきかということです。 言い換えると,すべてのプロセスがほぼ同じ性能を持つようにしたいか, 特定のプロセスに焦点を当てて,それらを可能な限り効率化したいかということです。 OpenVMS の 1 つのインスタンスが複数の RAD 上で実行されるときには (マシン全体,ハード・パーティション,または Galaxy インスタンスを問わない), 必ずこの質問に対する答えを用意しなければなりません。 その答えに応じて,構成と管理に関するいくつかの決定を行う必要があるからです。 OpenVMS の省略時の NUMA 動作モードは「すべてに対して一様」です。 リソースは,長期的に見ると,システム上のすべてのプロセスが, 平均してほぼ同等の性能ポテンシャルを持つように割り当てられます。 「すべてに対して一様」のモードを希望しない場合には, より特殊な「少数に対して最適化」または「専用」環境を実現するためのインタフェースを理解する必要があります。 特定のリソースにプロセスとデータを割り当てて, それらの性能ポテンシャルを最大限に高めることが可能です。 NUMA 環境に関する理解を深めるために,この章では以下のことを説明します。
OpenVMS のメモリ管理とプロセス・スケジューリングは, AlphaServer GS Series システム・ハードウェア上でより効率的に動作するように強化されています。 以下に示す強化分野は,それぞれシステムに新しい能力を付加しています。 個別に見れば, これらは特定のアプリケーション・ニーズの性能ポテンシャルを高めています。 全体として見れば,これらは多様なアプリケーション・ミックスに必要な環境を提供していると言うことができます。新たに対処された分野は次のとおりです。
CPU は,同じ RAD 内のメモリの方が, 別の RAD 内のメモリよりも 3 倍の速度で参照することができます。 このため,実行されるコードと参照されるメモリを, 可能な限り同じ RAD に入れておくことが重要となります。 優れた性能を実現するためには,一貫して適切な位置を確保することが鍵となります。 性能を評価するにあたって, プログラマは次のような質問を考慮に入れる必要があります。
OpenVMS スケジューラとメモリ管理サブシステムは,以下の方法で, 最適な位置を決定します。
OpenVMS オペレーティング・システムは,プロセスの作成中に, 個々のプロセスにホーム RAD を割り当てます。 これには 2 つの大きな意味があります。 第 1 に,ごく少数の例外を除き, プロセスのホーム RAD に含まれる CPU の 1 つがプロセスを実行することになります。 第 2 に,プロセスが必要とするすべてのプロセス・プライベート・ページが, ホーム RAD に含まれるメモリから割り当てられるようになります。 この組み合わせにより,ローカル・メモリ参照が行われる可能性が最大化されます。 ホーム RAD を割り当てるときの OpenVMS のデフォルトの動作は, プロセスを RAD 間に分散させるというものです。 システムのスタートアップ時には, オペレーティング・システム・コードが各 RAD のメモリに複製されます。 これにより,システム内のプロセスは, システム機能が必要になったときにはローカル・メモリにアクセスするようになります。 この複製は,エグゼクティブ・コードとインストール済み常駐イメージ・コードの粒度ヒント領域の両方について行われます。 アプリケーション環境はそれぞれ異なる性質を持っています。 アプリケーションの構造によって, 望ましい目標を達成するための最適なオプションが決まります。 これらの決定要因の例を以下に示します。
絶対的な規則はあまりありませんが,以下の項では, 一般に最適な結果をもたらす基本的な概念と例をいくつか示します。 メモリ・アクセスの (RAD 上での) ローカル化は常に目標となりますが, これは必ずしも達成可能ではなく, トレードオフを判断しなければならない可能性が高いと考えられます。 1 つのグローバル・セクションにアクセスするプロセスが数百あるいは数千もある場合には, オペレーティング・システムのデフォルトの動作を使用するのが適しています。 グローバル・セクションのページは,すべての RAD のメモリに均等に分散され, プロセスのホーム RAD の割り当ては CPU 間で均等に分散されます。 これは,グローバル・セクションへのアクセスがランダムだった場合に, すべてのプロセスが似たような性能ポテンシャルを持つことになる分散効果, つまり「一様」効果です。どのプロセスも最適化はされませんが, 他のプロセスと比べて極端に不利なプロセスも出現しません。 一方,少数のプロセスがグローバル・セクションにアクセスする場合には, 4 つの CPU で処理負荷を扱うことができ,1 つの RAD がグローバル・セクション全体を扱える十分なメモリを持っているという前提で,それらのプロセスを 1 つの RAD に配置することができます。 これにより,大部分のメモリ・アクセスがローカル化され, 配置されたプロセスの性能が強化されます。 この戦略は,1 つのプロセスとデータのセットを 1 つの RAD に配置し, 別のプロセスとデータのセットを別の RAD に配置するというように, 同じシステム上で繰り返し採用することができます。 AlphaServer GS シリーズのシステムには,大量のメモリを搭載することができます。 可能な限り,大きなメモリ容量を有効に活用してください。 たとえば,コードやデータを複数の RAD に複製するようにします。 ある程度の分析が必要となり,スペースの無駄に見えるかもしれず, 調整も必要となります。 しかし,これによって最終的にローカルなメモリ参照が大幅に増えるのであれば, その価値はあります。 RAM ディスク・プロダクトの使用を検討してください。 NUMA が使用されている場合でも,メモリ内参照は実際の装置 I/O よりも高性能です。 一般に,データを共用するためには同期処理が必要となります。 1 つのメモリ位置を調整メカニズムとして使用している場合 (ラッチ,ロック,セマフォなどと呼ばれます) には, それが多くのリモート・アクセスの原因となっていて, 競合レベルが高くなると性能を低下させる可能性があります。 この種のロックをデータ全体に複数のレベルで分散させることで, リモート・アクセスの量を減らせることがあります。 このセクションでは, NUMA 環境でのリソース・アフィニティ・ドメイン (RAD) のサポートにおける OpenVMS バッチ処理サブシステムのアップデートについて説明します。 システム管理者は, NUMA 環境のリソース・アフィニティ・ドメイン (RAD) の特定のサポートにバッチ・キューを割り当てることができ, ユーザはバッチ・ジョブを実行する RAD を指定することができます。 これらの新機能の使用は,バッチ実行キューとバッチ・ジョブに制限されます。 DCL コマンドの説明については,『OpenVMS DCL ディクショナリ』を参照してください。 DCL コマンドの INITIALIZE/QUEUE,SET/QUEUE,および START/QUEUE で新しい修飾子 /RAD を使用することができます。 システム管理者は,キューに割り当てられたバッチ・ジョブを実行する RAD 番号を指定します。 RAD 値は, 0 から SYI$_RAD_MAX_RADS までの正の整数であることが検証されます。 SHOW/QUEUE/FULL コマンドの出力に RAD が表示されるようになり, F$GETQUI レキシカル関数は新しい RAD 項目を受け入れるようになりました。 ここでは,コマンドのシーケンスとバッチ・キューへの効果を説明します。 バッチ・キューの変更を示すために,それぞれの例に SHOW コマンドが含まれています。
新しい修飾子 /RAD は,DCL コマンドの SUBMIT と SET/ENTRY に追加されます。 ユーザは登録したバッチ・ジョブを実行する RAD 番号を修飾子の値で指定します。 SHOW ENTRY および SHOW QUEUE/FULL コマンドが強化されて, バッチ・ジョブの RAD 設定をリストするようになりました。 RAD 設定のないバッチ・キューにジョブが登録されたときには, そのジョブは SUBMIT コマンドで指定された RAD を使用して実行します。 次のコマンドは,TEST.COM をキュー ANYRADQ に登録します。 ANYRADQ キューには RAD 設定はありません。
RAD 設定のあるバッチ・キューにジョブが登録されたときには, そのジョブは,SUBMIT コマンドで指定された RAD に関係なく, キューに対して指定された RAD を使用して実行します。 この動作は,他のバッチ・システム機能と一貫性があります。 キュー BATCHQ1 は,/RAD=0 として定義されています。 次の SUBMIT コマンドの例では,ユーザは登録時に RAD 1 を指定しましたが, RAD 0 で実行するジョブが作成されます。
バッチ・ジョブの RAD を指定すると, ジョブ・コントローラは新しい HOME_RAD 引数がジョブの RAD 値に設定されたプロセスを作成します。 ジョブに対して指定された RAD がターゲット・システムで無効であった場合, ジョブ・コントローラは BADRAD メッセージをオペレータ・コンソールに出力します。 正しくない RAD 値がバッチ・キューの RAD 設定に一致した場合, バッチ・キューは停止します。ジョブはキューに残ります。 次の例は,実行時処理のエラーを示しています。
アプリケーション・プログラマとシステム管理者は, システムの省略時の値が運用環境のニーズを満たせない場合には, RAD に固有の多数のインタフェースを使ってプロセスとメモリのロケーションを制御することができます。 以下の項は簡単な説明です。 詳細については『OpenVMS System Services Reference Manual』を参照してください。 プロセスの作成 プロセスに特定のホーム RAD を持たせたい場合は, SYS$CREPRC システム・サービスの新しい HOME_RAD 引数を使用します。 これにより,アプリケーションからロケーションを制御することができます。 プロセスの移動 プロセスがすでに作成されており,これを再配置したい場合には,システム・サービス SYS$PROCESS_AFFINITY または SYS$PROCESS_CAPABILITY で CAP$M_PURGE_WS_IF_NEW_RAD フラグを使用します。 アフィニティまたはケーパビリティの選択によってプロセスのホーム RAD が変わる場合には,プロセスのワーキング・セットは削除されます。 プロセスに関する情報の取得 SYS$GETJPI システム・サービスは,プロセスのホーム RAD を返します。 グローバル・セクションの作成 SYS$CRMPSC_GDZRO_64 および SYS$CREATE_GDZRO システム・サービスは RAD 引数マスクを受け付けます。 これは,OpenVMS がグローバル・セクションのページをどの RAD に割り当てるかを指定します。 予約済みメモリの割り当て 予約済みメモリの割り当てのための SYSMAN インタフェースは RAD 修飾子を持っているので,システム管理者は特定の RAD のメモリを予約することができます。 システムに関する情報の取得 SYS$GETSYI システム・サービスは, RAD 情報を獲得するために使われる以下の項目コードを定義しています。
RAD_SUPPORT システム・パラメータ RAD_SUPPORT システム・パラメータは,個々の RAD 関連の動作をカスタマイズするために定義されている多くのビットとフィールドを持っています。 これらのビットについての詳細は,3.7.1 項 「SHOW RAD」の例を参照してください。 次の表は, OpenVMS Version 7.3 以降の RAD システム・サービスに関する情報を示しています。 詳細については,『OpenVMS System Services Reference Manual』を参照してください。
次の表は,OpenVMS RAD DCL コマンドを要約したものです。 詳細については,『OpenVMS DCL ディクショナリ』を参照してください。 以下に示す System Dump Analyzer (SDA) コマンドには RAD サポートが追加されています。
SDA コマンドの SHOW RAD は,以下の情報を表示します。
このコマンドは, RAD をサポートするハードウェア・プラットフォームでのみ有効です (AlphaServer GS160 システムなど)。 デフォルトの設定では,SHOW RAD コマンドは RAD_SUPPORT システム・パラメータ・フィールドの設定を表示します。 形式:
パラメータ: number 指定された RAD の CPU とメモリに関する情報を表示します。 修飾子: /ALL RAD_SUPPORT パラメータ・フィールドの設定とすべての CPU/ メモリ割り当てを表示します。 次の例は,RAD_SUPPORT システム・パラメータ・フィールドの設定を示しています。
次の例は,RAD 2 の CPU とメモリに関する情報を示しています。
SDA コマンドの SHOW RMD は,予約済みメモリの割り当て元の RAD を示すように 拡張されています。予約済みメモリの割り当て時に RAD が指定されていなかった場合, SDA は ANY と表示します。 SET PROCESS コマンドが強化されて,/AFFINITY 修飾子が追加されました。 /AFFINITY 修飾子によって, カーネル・スレッドのアフィニティ・マスクのビットをセットまたはクリアできます。 アフィニティ・マスクのビットは,個別に操作することも, グループ単位や全部を一括して操作することもできます。 /NOAFFINITY 修飾子は,/PERMANENT 修飾子の設定に基づいて, 現在またはパーマネント・アフィニティ・マスクでセットされているすべてのアフィニティ・ビットをクリアします。 /AFFINITY 修飾子を指定しても直接の効果はなく, 次の 2 次パラメータによって指定された操作のターゲットを示すだけです。
次の例は, CPU 1,2,3,および 5 のアフィニティ・ビットをアクティブにセットする方法を示しています。
RAD をサポートしているシステムでは,1 つのプロセスに対するアフィニティを設定する CPU のセットは同じ RAD 内に存在していなければなりません。 たとえば,RAD 0 に CPU 0,1,2,3 があり,RAD 1 に CPU 4,5,6,7 がある AlphaServer GS160 では,SET = 2,3,4,5 は良い設定ではありません。 全体の半分が,ホーム RAD の外で実行されることになるからです。 |
![]() |
|||||||||||||||
|