| 前へ | 次へ | 目次 | 索引 |
特定のシステム・イベントが発生したときに，アプリケーションにそのことを通知するように登録することができます。たとえば，インスタンスが galaxy に参加したり，CPU が構成セットに参加したときに，そのことを通知できます。イベントが登録されると，アプリケーションは登録されたイベントの発生時にどのように応答するかを判断できます。
表 2-2 はイベント・プログラミングのための OpenVMS システム・サービスについてまとめています。
| システム・サービス | 説明 |
|---|---|
| $CLEAR_SYSTEM_EVENT | SYS$SET_SYSTEM_EVENT を呼び出すことで設定された 1 つ以上の通知要求を削除します。 |
| $SET_SYSTEM_EVENT | OpenVMS システム・イベントが発生したときに，それを通知するための要求を設定します。 |
2.14.3 OpenVMS Galaxy での System Dump Analyzer (SDA) の使用
この節では，OpenVMS Galaxy 環境に特定した System Dump Analyzer (SDA) について説明します。
SDA の使い方の詳細については，『OpenVMS Alpha System Analysis Tools Manual』を参照してください。
2.14.3.1 共用メモリのダンプ
Galaxy インスタンスでシステム・クラッシュが発生した場合，OpenVMS はデフォルトの動作として，障害が発生したインスタンスのプライベート・メモリの内容と，共用メモリの内容をダンプします。完全なダンプの場合，共用メモリとプライベート・メモリのすべてのページがダンプされます。選択型ダンプの場合は，システム・クラッシュが発生した時点で使用されていたページだけがダンプされます。
共用メモリのダンプは，動的 SYSGEN パラメータ DUMPSTYLE のビット 4 をセットすることで無効に設定できます。このビットは，"弊社のサポート要員" から助言があった場合にだけセットするようにしてください。このビットをセットすると，システム・クラッシュの原因を判断するのに必要なデータがシステム・ダンプに含まれなくなる可能性があります。
表 2-3 は，DUMPSTYLE のすべてのビットの定義と，OpenVMS Alpha での各ビットの意味を示しています。ビットはどの組み合わせでも指定できます。
| ビット | 値 | 説明 |
|---|---|---|
| 0 | 1 | 0= 完全なダンプ。物理メモリ全体の内容がダンプ・ファイルに書き込まれる。
1= 選択型ダンプ。ダンプ・ファイルの有用性をできるだけ高め，その一方でディスク空間を節約できるように，メモリの内容が選択的にダンプ・ファイルに書き込まれる ( 使用中のページだけが書き込まれる )。 |
| 1 | 2 | 0= 最小コンソール出力。この出力には，バグチェック・コード，クラッシュが発生した CPU，プロセス，イメージの ID，システム日時，ダンプの出力の進行状況を示す一連のドットが含まれる。
1= 完全なコンソール出力。前に説明した最小出力の他に，スタックとレジスタの内容，システム・レイアウトも出力され，ダンプの進行状況を示すためにダンプ中のプロセスの名前なども出力される。 |
| 2 | 4 | 0= システム・ディスクへのダンプ。ダンプは SYS$SYSDEVICE:[SYSn.SYSEXE]SYSDUMP.DMP に書き込まれる。このファイルがない場合は，SYS$SYSDEVICE:[SYSn.SYSEXE]PAGEFILE.SYS に書き込まれる。
1= 別のディスクへのダンプ。ダンプは dump_dev:[SYSn.SYSEXE]SYSDUMP.DMP に書き込まれる。ただし，DUMP_DEV はコンソール環境変数 dump_dev の値である。 |
| 3 | 8 | 0= 非圧縮ダンプ。ページはダンプ・ファイルに直接書き込まれる。
1= 圧縮ダンプ。各ページは書き込む前に圧縮されるので，ダンプを書き込むのに必要な空間と時間を節約できる。一方，ダンプにアクセスするのに必要な時間は少し長くなる。 |
| 4 | 16 | 0= 共用メモリをダンプする。
1= 共用メモリをダンプしない。 |
DUMPSTYLE のデフォルト設定は 0 です ( つまり，共用メモリも含めて，完全なダンプを圧縮せずにシステム・ディスクに書き込みます )。DUMPSTYLE の値が MODPARAMS.DAT に指定されていない場合は，AUTOGEN.COM はシステムのメモリが 128 MB 未満の場合は 1 に ( 共用メモリも含めて，選択型ダンプを圧縮せずにシステム・ディスクに書き込みます )，128 MB 以上の場合は 9 に ( 共用メモリも含めて，選択型ダンプを圧縮してシステム・ディスクに書き込みます ) 設定します。
2.14.3.2 SDA コマンド・インタフェースの変更または追加についてのまとめ
次のリストは，System Dump Analyzer (SDA) が共用メモリおよび OpenVMS Galaxy データ構造を表示するために，どのように拡張されたかをまとめています。詳細については適切なコマンドを参照してください。
NUMA (nonuniform memory access) とは，特定の物理メモリ位置へのアクセス時間が，すべての CPU で同じにならないというシステムの属性のことです。このアーキテクチャの下で高い性能を実現するためには，(100 パーセンントとはいかなくても ) 一貫して適切なロケーションを確保する必要があります。AlphaServer GS シリーズでは，CPU は自分の QBB の中のメモリに，他の QBB の中のメモリよりも高速にアクセスすることができます。
OpenVMS が 1 つの QBB のリソース上で実行されている場合には，NUMA による影響はなく，ここでの説明は適用されません。可能性と実現性がある場合，できるだけ 1 つの QBB の中で実行することで UMA の複雑な影響をなくし，高い性能を引き出すことができます。
NUMA 環境における全体的なシステム性能に関して最も多い質問は，"すべてに対して一様" と "少数に対して最適化" のどちらを選ぶべきかということです。言い換えると，すべてのプロセスがほぼ同じ性能を持つようにしたいか，特定のプロセスに焦点を当てて，それらを可能な限り効率化したいかということです。OpenVMS の 1 つのインスタンスが複数の QBB 上で実行されるときには ( マシン全体，ハード・パーティション，または Galaxy インスタンスを問わない )，必ずこの質問に対する答えを用意しなければなりません。その答えに応じて，構成と管理に関するいくつかの決定を行う必要があるからです。
OpenVMS の省略時の NUMA 動作モードは「すべてに対して一様」です。リソースは，長期的に見ると，システム上のすべてのプロセスが，平均してほぼ同等の性能ポテンシャルを持つように割り当てられます。
「すべてに対して一様」のモードを希望しない場合には，より特殊な「少数に対して最適化」または「専用」環境を実現するためのインタフェースを理解する必要があります。特定のリソースにプロセスとデータを割り当てて，それらの性能ポテンシャルを最大限に高めることが可能です。
NUMA 環境に関する理解を深めるために，本章では以下のことを説明します。
OpenVMS のメモリ管理とプロセス・スケジューリングは，AlphaServer GS Series システム・ハードウェア上でより効率的に動作するように強化されています。
オペレーティング・システムは，ハードウェアをリソース・アフィニティ・ドメイン (RAD) のセットとして扱います。RAD は，共通のアクセス特性を持つ物理的リソース (CPU，メモリ，および I/O) のソフトウェア上の分類です。AlphaServer GS Series システムでは，RAD は Quad Building Block (QBB) に対応します。OpenVMS の 1 つのインスタンスが複数の QBB 上で実行されているとき，QBB は OpenVMS からは RAD と見なされます。
以下に示す強化分野は，それぞれシステムに新しい能力を付加しています。個別に見れば，これらは特定のアプリケーション・ニーズの性能ポテンシャルを高めています。全体として見れば，これらは多様なアプリケーション・ミックスに必要な環境を提供していると言うことができます。新たに対処された分野は次のとおりです。
CPU は，同じ RAD 内のメモリの方が，別の RAD 内のメモリよりも 3 倍の速度で参照することができます。このため，実行されるコードと参照されるメモリを，可能な限り同じ RAD に入れておくことが重要となります。優れた性能を実現するためには，一貫して適切な位置を確保することが鍵となります。性能を評価するにあたって，プログラマは次のような質問を考慮に入れる必要があります。
OpenVMS スケジューラとメモリ管理サブシステムは，以下の方法で，最適な位置を決定します。
OpenVMS オペレーティング・システムは，プロセスの作成中に，個々のプロセスにホーム RAD を割り当てます。これには 2 つの大きな意味があります。第 1 に，ごく少数の例外を除き，プロセスのホーム RAD に含まれる CPU の 1 つがプロセスを実行することになります。第 2 に，プロセスが必要とするすべてのプロセス・プライベート・ページが，ホーム RAD に含まれるメモリから割り当てられるようになります。この組み合わせにより，ローカル・メモリ参照が行われる可能性が最大化されます。
ホーム RAD を割り当てるときの OpenVMS のデフォルトの動作は，プロセスを RAD 間に分散させるというものです。
3.1.2 システム・コードの複製
システムのスタートアップ時には，オペレーティング・システム・コードが各 RAD のメモリに複製されます。これにより，システム内のプロセスは，システム機能が必要になったときにはローカル・メモリにアクセスするようになります。この複製は，エグゼクティブ・コードとインストール済み常駐イメージ・コードの粒度ヒント領域の両方について行われます。
3.1.3 グローバル・ページの分散
OpenVMS のデフォルトの動作は，RAD 間でグローバル・ページ ( グローバル・セクションのページ ) を分散させるというものです。このアプローチは，システム・スタートアップ時に予約済みメモリとして宣言されたグローバル・ページの割り当ての際にも使用されます。
3.2 アプリケーション・リソースに関する注意事項
アプリケーション環境はそれぞれ異なる性質を持っています。アプリケーションの構造によって，望ましい目標を達成するための最適なオプションが決まります。これらの決定要因の例を以下に示します。
絶対的な規則はあまりありませんが，以下の項では，一般に最適な結果をもたらす基本的な概念と例をいくつか示します。メモリ・アクセスの (QBB 上での ) ローカル化はつねに目標となりますが，これは必ずしも達成可能ではなく，トレードオフを行わなければならない可能性が高いと考えられます。
3.2.1 プロセスと共用データ
1 つのグローバル・セクションにアクセスするプロセスが数百あるいは数千もある場合には，オペレーティング・システムのデフォルトの動作を使用するのが適しています。グローバル・セクションのページは，すべての RAD のメモリに均等に分散され，プロセスのホーム RAD の割り当ては CPU 間で均等に分散されます。これは，グローバル・セクションへのアクセスがランダムだった場合に，すべてのプロセスが似たような性能ポテンシャルを持つことになる分散効果，つまり「一様」効果です。どのプロセスも最適化はされませんが，他のプロセスと比べて極端に不利なプロセスも出現しません。
一方，少数のプロセスがグローバル・セクションにアクセスする場合には，4 つの CPU で処理負荷を扱うことができ，1 つの RAD がグローバル・セクション全体を扱える十分なメモリを持っているという前提で，それらのプロセスを 1 つの RAD に「配置する」ことができます。これにより，大部分のメモリ・アクセスがローカル化され，配置されたプロセスの性能が強化されます。この戦略は，1 つのプロセスとデータのセットを 1 つの RAD に配置し，別のプロセスとデータのセットを別の RAD に配置するというように，同じシステム上で繰り返し採用することができます。
3.2.2 メモリ
1 つの QBB は 32GB までのメモリを，2 つの QBB は 64GB までのメモリを持つことができます (以下同様)。可能な限り，大きなメモリ容量を有効に活用してください。たとえば，コードやデータを複数の RAD に複製するようにします。ある程度の分析が必要となり，スペースの無駄に見えるかもしれず，調整も必要となります。しかし，これによって最終的にローカルなメモリ参照が大幅に増えるのであれば，その価値はあります。
RAM ディスク・プロダクトの使用を検討してください。NUMA が使用されている場合でも，メモリ内参照は実際の装置 I/O よりも高性能です。
3.2.3 共用と同期処理
一般に，データを共用するためには同期処理が必要となります。1 つのメモリ位置を調整メカニズムとして使用している場合 ( ラッチ，ロック，セマフォなどと呼ばれます ) には，それが多くのリモート・アクセスの原因となっていて，競合レベルが高くなると性能を低下させる可能性があります。この種のロックをデータ全体に複数のレベルで分散させることで，リモート・アクセスの量を減らせることがあります。
3.2.4 OpenVMS 機能の使用
一部の基本オペレーティング・システム機能を頻繁に使用すると，これらの機能をサポートするデータが QBB0 のメモリ内に存在しているために，多数のリモート・アクセスが発生します。データの中には，複製できないもの，また複製は可能であるがまだ実現されていないものがあります。
3.3 NUMA リソース・アフィニティ・ドメインのバッチ・ジョブ・サポート
このセクションでは，NUMA 環境でのリソース・アフィニティ・ドメイン (RAD) のサポートにおける OpenVMS バッチ処理サブシステムのアップデートについて説明します。
システム管理者は，NUMA 環境のリソース・アフィニティ・ドメイン (RAD) の特定のサポートにバッチ・キューを割り当てることができ，ユーザはバッチ・ジョブを実行する RAD を指定することができます。
これらの新機能の使用は，バッチ実行キューとバッチ・ジョブに制限されます。
DCL コマンドの説明については，『OpenVMS DCL ディクショナリ』を参照してください。
3.3.1 バッチ・キュー・レベルの RAD サポート
DCL コマンドの INITIALIZE/QUEUE，SET/QUEUE，および START/QUEUE で新しい修飾子 /RAD を使用することができます。システム管理者は，キューに割り当てられたバッチ・ジョブを実行する RAD 番号を指定します。
RAD 値は，0 から SYI$_RAD_MAX_RADS までの正の整数であることが検証されます。SHOW/QUEUE/FULL コマンドの出力に RAD が表示されるようになり，F$GETQUI レキシカル関数は新しい RAD 項目を受け入れるようになりました。
3.3.1.1 例
ここでは，コマンドのシーケンスとバッチ・キューへの効果を説明します。バッチ・キューの変更を示すために，それぞれの例に SHOW コマンドが含まれています。
$ INITIALIZE/QUEUE/ON=QUEBIT::/BATCH/RAD=0 BATCHQ1 $ SHOW QUEUE/FULL BATCHQ1 Batch queue BATCHQ1, stopped, QUEBIT:: /BASE_PRIORITY=4 /JOB_LIMIT=1 /OWNER=[SYSTEM] /PROTECTION=(S:M,O:D,G:R,W:S) /RAD=0 |
$ START/QUEUE/RAD=1 BATCHQ1 $ SHOW QUEUE/FULL BATCHQ1 Batch queue BATCHQ1, idle, on QUEBIT:: /BASE_PRIORITY=4 /JOB_LIMIT=3 /OWNER=[SYSTEM] /PROTECTION=(S:M,O:D,G:R,W:S) /RAD=1 |
$ SET/QUEUE/RAD=0 BATCHQ1 $ SHOW QUEUE/FULL BATCHQ1 Batch queue BATCHQ1, idle, on QUEBIT:: /BASE_PRIORITY=4 /JOB_LIMIT=3 /OWNER=[SYSTEM] /PROTECTION=(S:M,O:D,G:R,W:S) /RAD=0 |
$ SET/QUEUE/NORAD BATCHQ1 $ SHOW QUEUE/FULL BATCHQ1 Batch queue BATCHQ1, idle, on QUEBIT:: /BASE_PRIORITY=4 /JOB_LIMIT=3 /OWNER=[SYSTEM] /PROTECTION=(S:M,O:D,G:R,W:S) |
$ WRITE SYS$OUTPUT F$GETQUI("DISPLAY_QUEUE","RAD","BATCHQ1")
-1
|
| 前へ | 次へ | 目次 | 索引 |