|
注意:
|
Oracle Tuxedo CORBA JavaクライアントとOracle Tuxedo CORBA JavaクライアントORBはTuxedo 8.1で非推奨になり、サポートされなくなりました。すべてのOracle Tuxedo CORBA JavaクライアントおよびOracle Tuxedo CORBA JavaクライアントORBのテキスト・リファレンスとコード・サンプルは、サード・パーティ製のJava ORBライブラリを実装または実行する際の参考や、プログラマの参照用としてのみ使用してください。 |
サード・パーティのCORBA Java ORBのテクニカル・サポートは、各ベンダーによって提供されます。Oracle Tuxedoでは、サード・パーティのCORBA Java ORBに関する技術的なサポートまたはドキュメントは提供していません。
次の領域で正しい判断を行うことで、Oracle Tuxedoアプリケーションの機能が向上します。
|
•
|
インタフェースやサービスをサーバーにパッケージングする方法 |
|
•
|
オペレーティング・システムのIPCパラメータのチューニング方法 |
MSSQセットを使用すべき場合(Oracle Tuxedo ATMIサーバーのみ)
|
注意:
|
複数サーバー、単一キュー(MSSQ)セットは、Oracle Tuxedo CORBAサーバーではサポートされていません。 |
表4-1では、Oracle TuxedoサーバーでMSSQセットを使用する場合について説明します。
表4-1
MSSQセットを使用する場合と、使用しない場合
|
|
|
|
|
多数のサーバーがある場合。(妥協策は、多数のMSSQセットを使用することです。) |
|
|
バッファ・サイズが1つのキューでいっぱいになる場合。 |
|
|
|
|
|
キューがいっぱいになるほど長いメッセージがサービスに渡される場合。この場合、非ブロッキング送信が失敗するか、またはブロッキング送信がブロックされます。 |
サービスのターンアラウンド・タイムが最適であり、一貫性があることが重要視される場合。 |
サービスのターンアラウンド・タイムが最適であり、一貫性があることが重要視されない場合。 |
次の2つの例で、MSSQセットの使用が常に適切なわけではない理由を示します。
|
•
|
MSSQセットが適切に使用されているアプリケーションは、銀行に似ています。銀行では、すべての窓口で同じサービスが提供されており、顧客は行列に並んで、窓口が空くのを待ちます。この効率的なしくみにより、利用できるサービスを確実に最適な形で使用できます。 |
|
•
|
MSSQセットを使用しないほうがよいアプリケーションは、スーパーマーケットに似ています。スーパーマーケットでは、各レジで、一連の異なるサービスが提供されています。現金のみを受け取るレジもあれば、クレジット・カードを受け付けるレジもあり、さらに10個未満の商品を購入する顧客しか扱わないレジもあります。 |
Oracle Tuxedoでは、システム全体に対し、ロード・バランシングのアルゴリズムを使用するかどうかを制御できます。ロード・バランシングを使用すると、ロード・ファクタがシステム内の各サービスに適用され、各サーバーの負荷の合計を追跡できます。各サービス・リクエストは、負荷が最も少ない適切なサーバーに送信されます。
|
注意:
|
Oracle Tuxedo CORBAシステムでは、システム制御のロード・バランシングは自動的に有効化されます。 LDBAL=Nを指定しても、ロード・バランシングを無効化することはできません。 |
SERVICESセクションにあるロード・ファクタの割当て方法を決定するには、アプリケーションを継続的に稼働し、各サービスの実行にかかる平均時間を計算します。算出した平均時間を必要とするサービスの場合は、
LOAD値に50 (
LOAD=50)を割り当てます。算出した平均値よりも長い時間がかかるサービスの場合は、
LOAD>50とします。算出した平均値より短い時間で済むサービスの場合は、
LOAD<50とします。
実行された各サービスには、
LOADファクタが割り当てられ、これにより各サーバーが実行したサービスの負荷の合計が追跡されます。各サービス・リクエストは、負荷の合計が最も低いサーバーにルーティングされます。ルーティング先のサーバーの負荷合計は、リクエストされたサービスの
LOADファクタ分だけ増加します。
レプリケートされたサーバー・プロセスおよびグループの構成
レプリケートされたサーバー・プロセスおよびグループをOracle Tuxedoドメイン内で構成するには、次の手順に従います。
|
1.
|
テキスト・エディタを使用して、アプリケーションの UBBCONFIGファイルを編集します。 |
|
2.
|
GROUPSセクションで、構成するグループの名前を指定します。
|
|
3.
|
SERVERSセクションでは、レプリケートするサーバー・プロセスについて、 表4-2に記載のパラメータを指定します。
|
表4-2
SERVERSセクションで指定されるパラメータ
|
|
|
|
|
アプリケーション・サーバーを含む実行可能ファイルの名前を指定します。 |
|
|
サーバー・プロセスが所属するグループの名前を指定します。複数のグループに関係するサーバー・プロセスをレプリケートする場合は、各グループに1つずつサーバー・プロセスを指定します。 |
|
|
数値による識別子を指定し、サーバー・プロセスにユニークなIDを付与します。 |
|
|
アプリケーションの起動時に開始するサーバー・プロセスのインスタンス数を指定します。 |
|
|
同時に実行できるサーバー・プロセスの最大数を指定します。 |
MINおよび
MAXパラメータは、指定のサーバー・アプリケーションが指定のインタフェースでリクエストをどの程度まで並列処理できるかを指定します。実行時には、必要に応じて、システム管理者がリソースのボトルネックを調べて、新しいサーバー・プロセスを起動することができます(アプリケーションのスケーリングも行われます)。詳細は、
『Oracle Tuxedoアプリケーション実行時の管理』の実行中のアプリケーションのモニタリングに関する項を参照してください。
MAXパラメータは、インスタンスの最大数を制御します。ただし、Oracle Tuxedoはインスタンスを自動的に作成することはありません。システムは、指定された
MIN数値分のインスタンスを自動的に開始します。
MINと
MAXの間の場合は、システム管理者が手動で新規インスタンスを作成する必要があります。
MAXに到達すると、
tmboot、
tmadmin、または
TMIB APIによってエラーが返されます。
データベースの相互運用のためのOPENINFOパラメータの設定
Oracle XAデータベース・ソフトウェアと相互運用する場合にマルチスレッド・サーバーによるスレッドの使用を有効化するには、
リスト4-1に示されているように、
UBBCONFIGファイルの
GROUPSセクションにある
OPENINFOパラメータに
Threads=trueを追加する必要があります。詳細は、Oracle XAオンライン・ドキュメントを参照してください。
リスト4-1
OPENINFOパラメータへのThreads=trueの追加
OPENINFO="ORACLE_XA:Oracle_XA+Acc=P/scott/tiger+SesTm=100+LogDir=.+MaxCur=5+Threads=true"
マルチスレッド・サーバーの構成に使用するパラメータ
マルチスレッドCORBAサーバーの構成には、次のパラメータを使用します。これらのパラメータは、
UBBCONFIGファイルで設定します。
|
注意:
|
MAXOBJECTSパラメータは特にスレッドに適用するものではありませんが、このパラメータを増やしたほうがよい場合があります。マルチスレッド・アプリケーションは、任意の時点において、シングル・スレッド・アプリケーションよりも多くのオブジェクトをアクティブ化する可能性があるためです。
|
これらのパラメータの設定方法については、次のトピックを参照してください。
PRIOパラメータを使用して、Oracle Tuxedoインタフェースに優先度を割り当てることにより、アプリケーション内のデータ・フローを有効に制御できます。Oracle Tuxedoシステムで動作するCORBAアプリケーションの場合、
PRIOパラメータは、アプリケーションの
UBBCONFIGファイルの
INTERFACESセクションで名前を指定した各インタフェースに指定できます。
たとえば、サーバー1が、インタフェースA、B、およびCを提供するとします。インタフェースAおよびBの優先度は50、インタフェースCの優先度は70です。インタフェースCに対するリクエストは、AまたはBに対するリクエストより常に先にキューから取り出されます。AおよびBに対するリクエストは、互いに等しくキューから取り出されます。システムは、10回に1回の割合で先入れ先出し(FIFO)順序でリクエストをキューから取り出し、メッセージがキューで無制限に待機しないようにします。
tpsprio()呼出しを使用すると、優先度を動的に変更できます。ただし、選ばれたクライアントだけがインタフェースの優先度を高く設定できるようにします。サーバーがインタフェース・リクエストを行うシステムでは、サーバー・サイドから
tpsprio()を呼び出し、インタフェース呼出しの優先度を上げることができます。これによりユーザーは、必要なインタフェース・リクエストを待たずに済みます。
PRIOパラメータは、慎重に使用してください。キューのメッセージの順序(たとえばA、B、C)によっては、10回に1回の割合でしか、一部(AおよびBなど)がキューから取り出されません。つまり、サービスのパフォーマンスが低下し、ターンアラウンド・タイムが遅くなる可能性があります。
|
•
|
サーバーのキューにおけるインタフェースの優先度を決定します。 |
|
•
|
最も高い優先度が最優先されます。このインタフェースの発生する頻度は低くなります。 |
|
•
|
メッセージは、FIFOに基づき10回に1回取り出されるため、優先度の低いメッセージがキューにいつまでもとどまることはありません。レスポンス時間は、優先度の低いインタフェースでは問題になりません。 |
優先度を割り当てることで、最も重要なリクエストの処理はより効率的に行い、重要性の低いリクエストの処理は遅らせて行うことができます。また、特定のユーザーまたは特定の状況に対して優先度を付けることも可能です。
サーバーへのサービスのバンドル(Oracle Tuxedo ATMIサーバーのみ)
複数のサービスをサーバーの実行可能ファイルにパッケージ化する最も簡単な方法は、まったくパッケージ化しないことです。しかし、サービスをパッケージ化しないと、サーバーの実行可能ファイル、メッセージ・キューおよびセマフォの数が許容範囲を超える原因となります。サービスをまったくバンドルしない(まとめない)場合と細かくバンドルする(まとめる)場合では、それぞれ長所と短所があります。
|
•
|
サービスの機能が類似している - アプリケーション内に役割の類似するサービスがある場合は、それらのサービスを同じサーバーにバンドルできます。アプリケーション側は指定されたときに、すべてを提供するか、あるいは何も提供しません。たとえば bankappアプリケーションでは、 WITHDRAW、 DEPOSIT、および INQUIRYの各サービスはすべて、窓口操作です。サービスの管理は簡略化されます。 |
|
•
|
類似するライブラリがある - たとえば、同じ100Kのライブラリを使用する3つのサービスと、異なる100Kのライブラリを使用する3つのサービスがある場合、最初の3つのサービスをバンドルすると200Kの領域を節約できます。たいていの場合、同等の機能を持つサービスには、類似するライブラリがあります。 |
|
•
|
キュー - キューで処理できる範囲のサービスのみをサーバーにバンドルしてください。空のMSSQセットに追加された各サービスは、サーバーの実行可能モジュールのサイズにはあまり影響しません。また、システム上のキューの数にはまったく影響しません。ただし、キューがいっぱいになるとシステムのパフォーマンスは低下するため、対応策として別の実行可能モジュールを作成する必要があります。 |
|
•
|
呼出し依存型サービスの設定 - 同じサーバーに、お互いを呼び出すサービスを2つ以上設定しないでください。設定すると、サーバーは自身を呼び出し、デッドロックの原因となります。 |
Oracle Tuxedoのリリース8.0から、パフォーマンス・オプションが追加されました。これらのオプションにより、Oracle Tuxedoのインフラストラクチャで特定の機能を無効化できます。無効化するのは、CORBAまたはATMIアプリケーションで必要でない機能のみとしてください。
表4-3で、これらのオプションを説明します。
|
|
|
|
サービスおよびインタフェースのキャッシュ・オプション( SICACHEENTRIESMAXおよび TMSICACHEENTRIESMAX) |
このオプションにより、サービスおよびインタフェースのエントリをキャッシングし、掲示板をロックすることなくサービスまたはインタフェースのキャッシングしたコピーを使用できます。 |
|
|
|
マルチスレッド処理を無効化するには、このオプションを「yes」に設定します。このスレッドを使用しないアプリケーションで、これらを無効にすると、パフォーマンスが著しく向上します。 |
|
認可と監査の無効化(オプション{ [NO_AA]}) |
このオプションを設定すると、アプリケーションごとに監査および認可の機能を無効化できます。 |
このオプションの設定は、UBBCONFIGファイルのRESOURCESセクションで行います。詳細は、 『Oracle Tuxedoアプリケーション実行時の管理』、および 『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』に記載された「UBBCONFIG(5)」の「RESOURCES」セクション内にある「OPTION」を参照してください。 |
|
|
このオプションを設定すると、XAトランザクションを無効化できます。 |
|
これらのアプリケーション・パラメータを設定することにより、システム効率を向上できます。
MAXDISPATCHTHREADSパラメータは、各サーバー・プロセスで生成される、同時に実行できるディスパッチ・スレッドの最大数を決定します。このパラメータを指定する際には、次の事項を考慮してください。
|
•
|
MAXDISPATCHTHREADSの値によって、受信するリクエストを格納するために拡大できる最大サイズが決定されます。
|
|
•
|
MAXDISPATCHTHREADSのデフォルト値は1です。1より大きい値を指定した場合、特別なディスパッチ・スレッドが作成および使用されます。このディスパッチャ・スレッドは、スレッド・プールの最大サイズを決定するスレッド数には、含まれていません。
|
|
•
|
MAXDISPATCHTHREADSパラメータの値に1を指定すると、サーバー・アプリケーションがシングル・スレッド・サーバーとして構成されることを示します。1より大きい値を指定すると、サーバー・アプリケーションがマルチスレッド・サーバーとして構成されることを示します。
|
|
•
|
MAXDISPATCHTHREADSパラメータに指定する値は、 MINDISPATCHTHREADSパラメータに指定する値を下回っていてはいけません。
|
|
•
|
オペレーティング・システム・リソースにより、1つのプロセスで作成できるスレッドの最大数は制限されます。 MAXDISPATCHTHREADSは、その制限値より少ない、アプリケーションが必要とするアプリケーション管理スレッドの数を差し引いた値にします。 |
MAXDISPATCHTHREADSパラメータの値は、他のパラメータにも影響を与えます。たとえば、
MAXACCESSORSパラメータはOracle Tuxedoシステムへの同時アクセス数を制御し、各スレッドは1つのアクセッサとしてカウントされます。マルチスレッド・サーバーのアプリケーションの場合、各サーバーの実行が構成されているシステム管理のスレッドの数を考慮しておく必要があります。
システム管理の
スレッドとは、アプリケーションで開始され管理されるスレッドとは対照的に、Oracle Tuxedoソフトウェアで開始され管理されるスレッドです。内部ではOracle Tuxedoが、利用可能なシステム管理のスレッドのプールを管理しています。クライアント・リクエストが受信されると、スレッド・プールから利用可能なシステム管理のスレッドがそのリクエストを実行するように、スケジューリングされています。リクエストが完了すると、システム管理のスレッドは利用可能なスレッドのプールに返されます。
たとえば、システム内に4つのマルチスレッド・サーバーがあり、各サーバーが50個のシステム管理のスレッドを実行するように構成されている場合、これらのサーバーにおけるアクセサ要件は、次のように計算される、アクセサ数の合計となります。
50 + 50 + 50 + 50 = 200アクセッサ
サーバーが最初にブートされたときに開始されるサーバー・ディスパッチ・スレッドの数を指定するには、
MINDISPATCHTHREADSパラメータを使用します。このパラメータを指定する際には、次の事項を考慮してください。
|
•
|
MINDISPATCHTHREADSの値によって、スレッド・プール内のスレッドの初期割当てが決定されます。
|
|
•
|
MAXDISPATCHTHREADSが1より大きい場合に作成される別個のディスパッチャ・スレッドは、 MINDISPATCHTHREADSの範囲には含まれません。
|
|
•
|
MINDISPATCHTHREADSに指定する値は、 MAXDISPATCHTHREADSに指定する値を上回ってはいけません。
|
|
•
|
MINDISPATCHTHREADSのデフォルト値は0です。
|
MAXACCESSERS、MAXOBJECTS、MAXSERVERS、MAXINTERFACES、およびMAXSERVICESパラメータの設定
MAXACCESSERS、
MAXOBJECTS、
MAXSERVERS、
MAXINTERFACES、および
MAXSERVICESの各パラメータを使用すると、セマフォおよび共有メモリーのコストが増大するため、システムの要求を満たす最低限の値を選択してください。また、システムに同時にアクセスできるクライアント数を設定できるようにしておく必要もあります。これらのパラメータには、デフォルトでIPCリソースが適度に割り当てられています。しかし、アプリケーションにとって必要最低限の値を設定するのが賢明です。
マルチスレッド・サーバーの場合、各サーバーの実行が構成されているスレッドの数を考慮しておく必要があります。
MAXACCESSERSパラメータは、Oracle Tuxedoシステムの同時アクセッサの最大数を設定します。アクセッサには、ネイティブおよびリモートのクライアント、サーバー、および管理プロセスが含まれます。MAXACCESSERSパラメータの設定の詳細は、
4-10ページの「MAXDISPATCHTHREADS」を参照してください。
MAXGTT、MAXBUFTYPE、およびMAXBUFSTYPEパラメータの設定
システム内のクライアント数と、それらのクライアントがトランザクションをコミットする時間の割合を乗算した積が100に近い場合は、
MAXGTTパラメータの値を増やす必要があります。コミットの速度に応じて、これには大量のクライアントが必要になる場合があります。
MAXGTTを増やす場合は、各マシンの
TLOGSIZEもそれに応じて増やす必要があります。分散トランザクションを使用しないアプリケーションでは、
MAXGTTを
0に設定する必要があります。
アプリケーションで受け付けられるバッファのタイプおよびサブタイプの数はそれぞれ、
MAXBUFTYPEパラメータおよび
MAXBUFSTYPEパラメータで制限できます。
MAXBUFTYPEの現在のデフォルト値は16です。ユーザー定義のバッファ・タイプが多数指定されていないかぎり、
MAXBUFTYPEは省略できます。しかし、何種類もの
VIEWサブタイプを使用する予定がある場合は、
MAXBUFSTYPEの設定を、現在のデフォルト値である
32より増やしておきます。
SANITYSCAN、BLOCKTIME、BBLQUERY、およびDBBLWAITパラメータの設定
システムが遅いプロセッサで稼働している場合(使用率が高い場合など)、タイミング・パラメータである
SANITYCAN、
BLOCKTIME、および個々のトランザクションのタイムアウト値を増やします。ネットワークが遅い場合は、
BLOCKTIME、
BBLQUERYおよび
DBBLWAITパラメータの値を増やします。
表4-4では、アプリケーションのチューニングに使用できるシステム・パラメータを説明します。
表4-4
アプリケーションのチューニングに使用するシステム・パラメータ
|
|
|
MAXACCESSERS、 MAXOBJECTS、 MAXSERVERS、 MAXINTERFACES、および MAXSERVICES
|
必要最低限の値を設定します(IPCコストの関係上)。 |
MAXGTT、 MAXBUFTYPE、および MAXBUFSTYPE
|
MAXGTTの値を増やして、多数のクライアントを許容します。トランザクション処理を行わないアプリケーションでは、 MAXGTTを 0に設定します。
ユーザー定義のバッファ型を8つ以上作成する場合にかぎり、 MAXBUFTYPEを使用します。 何種類もの VIEWサブタイプを使用する場合は、 MAXBUFSTYPEの値を増やします。 |
BLOCKTIME、 TRANTIME、および SANITYSCAN
|
|
BLOCKTIME、 TRANTIME、 BBLQUERY、および DBBLWAIT
|
|
IPC要件は、様々なシステム・パラメータの値で決まります。
tmboot -cコマンドを使用すると、構成のIPC要件をテストできます。次のパラメータの値は、アプリケーションのIPC要件に影響をもたらします。
|
•
|
RQADDR (これを使用すると MSSQセットを形成できます)
|
表4-5では、アプリケーションで必要とされるIPCに影響を与えるシステム・パラメータについて説明します。
|
|
|
|
|
メッセージ・キューの数は、 MAXACCESSERS +応答キューを持つサーバー数( MSSQセットのサーバー数+ MSSQセット数)とほぼ同じです。 |
MAXSERVERS、MAXSERVICESおよびMAXGTT
|
MAXSERVERS、 MAXSERVICES、 MAXGTTの3つ、および ROUTING、 GROUP、 NETWORKの3つのセクションの全体のサイズは共有メモリーのサイズに影響し、これらのパラメータの相関関係を計算式に表そうとすると複雑になります。かわりに、単純に tmboot -cまたは tmloadcf -cを実行すると、アプリケーションで最低限必要なIPCのリソース要件を計算することができます。
|
|
|
クライアントとサーバー間のバッファ・トラフィックのフローを管理するためにチューニングします。キューの最大サイズ(バイト単位)は、アプリケーションで最も大きいメッセージを処理でき、通常は75 - 85パーセントが使用中になる大きさに設定します。それよりパーセンテージを低くすると、無駄が生じます。それより大きくすると、ブロックへのメッセージ送信頻度が高くなりすぎます。 アプリケーションが送信するメッセージに対して最大のバッファを処理できるように最大サイズを設定します。 キューの最大長(キューに同時にとどまることができる最大メッセージ数)は、アプリケーションにおける操作に適した大きさに設定する必要があります。 キューの平均使用率と平均長を測定するには、アプリケーションをシミュレートするか、または実行します。これは、アプリケーションの実行前にチューニング可能なパラメータを予測し、アプリケーションの実行後にパフォーマンス分析に基づいてそのパラメータを調整するという、試行錯誤のプロセスになります。 大規模なシステムでは、オペレーティング・システム・カーネルのサイズに対するパラメータ設定の効果を分析します。効果が認められない場合には、アプリケーション・プロセスの数を減らすか、アプリケーションをさらに多くのマシンに分散して MAXACCESSERSを減らします。 |
トラフィックの量がリソース容量の上限に近くなると、システムにボトルネックが生じる可能性があります。サービス・トラフィックを測定するには、実装コードでグローバル・カウンタを使用します。
たとえばTuxedoアプリケーションでは、ブート時に
tpsvrinit()が呼び出されると、グローバル・カウンタを初期化して、開始時間を記録できます。以降、特定のサービスが呼び出されるたびにカウンタ値は増加します。
tpsvrdone()関数を呼び出してサーバーを停止すると、最終カウンタと終了時間が記録されます。このメカニズムにより、一定期間に特定サービスのビジー状態がどの程度であるかを判断できます。
|
注意:
|
CORBA C++アプリケーションの場合は、 Server::initialize()および Server::release()操作を使用します。 |
Oracle Tuxedoでは、データ・フローのパターンが原因でボトルネックが生じます。ボトルネックを検出する最も早い方法は、クライアント側から関連するサービスに要する時間を測定することです。
クライアント1では、画面の出力に4秒必要であるとします。
time(2)を呼び出すと、サービスAに対する
tpcallが動作を3.7秒遅らせていることがわかります。サービスAを開始点と終了点でモニターすると、0.5秒かかっています。これは、キューがいっぱいであることを示唆しており、この判断は
pqコマンドを使用して行われます。
一方、サービスAの実行に3.2秒かかるとします。サービスAの個々の部分はまとめて測定できます。サービスAがサービスBに対して
tpcallを発行し、この動作に2.8秒かかっていることも考えられます。この場合、キュー時間またはメッセージ送信ブロッキング時間を分離できます。適切な時間を識別すると、アプリケーションはトラフィックを処理できるように再度チューニングされます。
time(2)を使用すると、次の項目の所要時間を測定できます。
|
•
|
サービス・リクエストを行うサービス機能(ある場合)。 |
UNIXシステムの
sar(1)コマンドを使用すると、システムのボトルネックの検出に役立つパフォーマンスについての情報が表示されます。
sar(1)コマンドは、次の目的に使用できます。
|
•
|
あらかじめ決められた間隔でオペレーティング・システムの累積アクティビティ・カウンタをサンプリングします。 |
表4-6は、
sar(1)コマンドのオプションの説明です。
|
|
|
|
|
CPUの使用率を示します。ユーザー・モード、システム・モード、待機状態(ブロックI/Oを待つプロセスを持ったままアイドル状態)、およびアイドル状態である時間を割合で示します。 |
|
|
バッファのアクティビティ(システム・バッファとディスクまたはほかのブロック・デバイスとの間で送信される1秒当たりのデータ転送数など)を報告します。 |
|
|
システム・コールのアクティビティを報告します。これには、すべての種類のシステム・コールと、 fork(2)や exec(2)などの特定のシステム・コールが含まれます。 |
|
|
システムのスワッピング・アクティビティをモニターします。これは、スワップ・インとスワップ・アウトの転送数などです。 |
|
|
専有時のキューの長さの平均および専有時間の割合を報告します。 |
|
|
メッセージとシステム・セマフォのアクティビティ(1秒当たりのプリミティブの数)を報告します。 |
|
|
ページング・アクティビティ(アドレス変換ページ・フォルト、ページ・フォルトと保護エラー、およびフリー・リストに再利用された有効ページなど)を報告します。 |
|
|
未使用のメモリー・ページとディスク・ブロック(ユーザー・プロセスで使用できる平均ページ数、プロセス・スワッピングに対して使用できるディスク・ブロックなど)を報告します。 |
|
注意:
|
一部のUNIXプラットフォームでは、 sar(1)コマンドはありませんが、かわりに同等のコマンドが用意されています。たとえば、BSDでは iostat(1)コマンドが用意されています。Sun Microsystems, Inc.では perfmeter(1)が用意されています。 |
Windowsでシステム情報を収集しボトルネックを検出するには、パフォーマンス・モニターを使用します。「スタート」メニューの「設定」をポイントして「コントロール・パネル」をクリックします。次に、「管理ツール」の「パフォーマンス」をクリックします。
