| ドキュメントのダウンロード | サイトマップ | 用語集 | |
|
|||
| bea ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > Tuxedo > Tuxedo アプリケーション実行時の管理 > BEA Tuxedo アプリケーションの監視 |
|
Tuxedo アプリケーション実行時の管理
|
BEA Tuxedo アプリケーションの監視
ここでは、次の内容について説明します。
アプリケーションの監視方法
システム管理者は、一度アプリケーションが起動して実行されたら、そのアプリケーションが実行中は企業の求めるパフォーマンス、可用性、セキュリティの各条件を満たすように管理する必要があります。このため、資源 (共用メモリなど)、アクティビティ (トランザクション処理など)、および発生する可能性のある問題 (セキュリティ違反など) について監視し、必要に応じて適切な処理を実行する必要があります。
管理者のこのような責務を実行するため、BEA Tuxedo システムには、システム・イベントおよびアプリケーション・イベントを監視し、システムを再コンフィギュレーションして性能を高めるための方法が用意されています。システムがどのように動作しているかを監視するには、以下の機能を使用します。
これらのツールを使用すると、変化し続けるビジネス上のニーズや、システムで発生した障害に対して、迅速かつ効率的に対応できます。また、これらのツールを使用して、アプリケーションの性能やセキュリティを管理することもできます。
図 2-1 監視ツール
BEA Tuxedo システムには、アプリケーションを監視するための次のようなツールが用意されています。
関連項目
システム・データとアプリケーション・データの監視
BEA Tuxedo システムを使用すると、システム・データおよびアプリケーション・データの監視を行うことができます。
システム・データを監視する
実行中のシステムを監視するため、BEA Tuxedo システムでは、次のシステム・コンポーネントに関するパラメータ設定を管理し、統計情報を生成します。
これらのコンポーネントには、MIB または tmadmin を使用してアクセスできます。また、管理者側で操作は行わず、掲示板の統計情報に基づいてシステム・コンポーネントが動的に変更されるようにシステムを設定することもできます。システムが正しくコンフィギュレーションされている場合は、次の機能を実行できます (掲示板で次の機能が指定されている場合)。
システムの管理データを監視することにより、アプリケーションの性能、可用性、およびセキュリティの低下の原因となる問題を防止したり、解決することができます。
システム・データの格納場所
システムを監視するために必要な情報を格納する場所として、BEA Tuxedo システムには次の 3 つのデータ・リポジトリが用意されています。
静的および動的な管理データを監視する
実行中の BEA Tuxedo システムでは、静的データと動的データという 2 種類の管理データを監視できます。
静的データとは
コンフィギュレーションの静的データとは、システムとアプリケーションを最初にコンフィギュレーションしたときに割り当てる設定値のことです。これらの設定値は変更されません (ただし、リアルタイムで変更したり、プログラムを使用して変更する場合は例外)。たとえば、システム全体に関するパラメータ (使用するマシン数など) やローカル・マシンのシステムに割り当てられた IPC 資源 (共用メモリなど) の容量は静的データです。静的データは、UBBCONFIG ファイルと掲示板に格納されます。
静的データの確認
コンフィギュレーションに関する静的データの確認が必要な場合があります。たとえば、コンフィギュレーション (または掲示板のマシン・テーブル) で許可されている最大マシン数の範囲内で、できるだけ多くのマシンを追加したい場合などです。この場合、システム全体に関するパラメータ (MAXMACHINES など) の現在の値を確認して、マシンの最大数を調べることができます。
システムをチューニングして、アプリケーションの性能を向上することもできます。チューニングが必要かどうかを決定するには、現在利用可能なローカル IPC 資源の容量を確認します。
動的データとは
コンフィギュレーションの動的データとは、アプリケーションの実行中にリアル・タイムで変更される情報のことです。たとえば、負荷 (サーバに送信されたリクエスト数) やコンフィギュレーションでのコンポーネント (サーバなど) の状態は、頻繁に変化します。動的データは、掲示板に格納されます。
動的データの確認
コンフィギュレーションの動的データは、管理上の問題を解決する場合に便利です。次に、具体的な例を 2 つ挙げます。
たとえば、スループットが低下し、現在接続中のクライアント数に対応できる十分なサーバが稼動しているかどうかを調べるとします。この場合、まず、実行中のサーバ数、接続されているクライアント数、および 1 つまたは複数のサーバの負荷を確認します。これらの値を確認すると、サーバの追加により性能を向上できるかどうかを判断できます。
また、アプリケーションに対して特定の要求を行ったときの応答が遅いというクレームを複数受け取ったとします。この場合は、負荷に関する統計情報を確認することにより、BLOCKTIME パラメータの値を増やして応答時間を短縮できるかどうかを判断することができます。
起動とシャットダウンに関する一般的な問題
BEA Tuxedo システムが正常に動作しているかどうかを確認する場合は、起動とシャットダウンに関する次の問題を考慮し、定期的にシステムを監視する必要があります。
起動時の一般的な問題
シャットダウン時の一般的な問題
適切な監視ツールを選択する
実行中のアプリケーションを監視するには、コンフィギュレーションの動的な局面を継続的にトラッキングし、静的なデータを不定期的に調査する必要があります。つまり、基本的には掲示板の情報に注目し、必要に応じて UBBCONFIG ファイルを参照します。次の要素を考慮した上で、適切な方法を選択してください。
次の表では、各監視ツールの使用方法を説明します。
BEA Administration Console を使用してアプリケーションを監視する
BEA Administration Console は、アプリケーションをチューニングしたり、変更するときに使用する MIB 用のグラフィカル・ユーザ・インターフェイスです。World Wide Web 経由でアクセスし、Web ブラウザを使用して表示します。管理者は、サポートされているブラウザを使用して BEA Tuxedo アプリケーションを監視できます。
ツールバーを使用してアクティビティを監視する
ツールバーには、管理や監視を行うツールを実行するための 12 のボタンが用意されています。各ボタンには、アイコンと名前が付いています。監視用のボタンは次のとおりです。
関連項目
コマンド行ユーティリティを使用してアプリケーションを監視する
コマンド行インターフェイスからアプリケーションを監視するには、tmadmin(1) コマンドまたは txrpt(1) コマンドを使用します。
tmadmin を使用してコンフィギュレーションを調べる
tmadmin コマンドは、掲示板とその関連エンティティを表示したり、変更するための 53 種類のコマンドのインタプリタです。tmadmin コマンドを使用すると、サービスの状態などのシステムの統計情報、実行済みのリクエスト数、キューに登録されているリクエスト数などを監視できます。
tmadmin コマンドを使用すると、BEA Tuxedo システムを動的に変更できます。たとえば、システムの実行中に次のような変更を行うことができます。
tmadmin セッションの開始時には、そのセッションの動作モードを選択できます。動作モードには、動作モード (デフォルト)、読み取り専用モード、コンフィギュレーション・モードがあります。
注記 BEA Tuxedo のバージョンとライセンス数に関するレポートを作成することもできます。
txrpt を使用してサーバとサービスに関するレポートを作成する
txrpt コマンドを実行すると、BEA Tuxedo サーバの標準エラー出力の分析が行われ、そのサーバでサービス処理にかかる時間のサマリが生成されます。レポートには、指定した期間内に各サービスのディスパッチが何回行われたか、また、各サービスではリクエストの処理にどれだけの時間がかかったかが記録されます。txrpt は、標準入力または入力用にリダイレクトされた標準エラー・ファイルからの入力を読み込みます。標準エラー・ファイルを作成するには、servopts(5) の選択肢から -r オプションを使用してサーバを起動します。-e servopts オプションを使用すると、ファイル名を指定できます。複数のファイルを、txrpt 用に 1 つの入力ストリームに連結することができます。
サービス X と、そのサービスが格納されたサーバ Y の情報がファイルに蓄積されます。txrpt を使用してこのファイルを処理すると、サービスのアクセス状況とサーバの処理時間に関するレポートが生成されます。
関連項目
tmadmin セッションのしくみ
tmadmin コマンドは、掲示板とその関連エンティティを表示したり、変更するための 53 種類のコマンドのインタプリタです。次の図は、典型的な tmadmin セッションの動作の例です。
図 2-2 典型的な tmadmin セッション
tmadmin コマンドを使用してシステムを監視する 以下は、tmadmin コマンドを使用して監視できる、実行時のシステムの機能の一覧です。
関連項目
イベント・ブローカを使用してアプリケーションを監視する
BEA Tuxedo のイベント・ブローカは、実行中のアプリケーションで発生するイベントを監視します。イベントとは、たとえば、クライアントの状態がアクティブから非アクティブに変わる、という MIB オブジェクトの状態の変化のことです。イベント・ブローカがイベントを検出すると、そのイベントはレポート (ポスト) され、イベントの発生がサブスクライバに通知されます。MIB オブジェクトを表す FML データ・バッファを受け取って、MIB でのイベントの発生通知を自動的に受け取ることもできます。イベントをポストしてサブスクライバにレポートする場合、イベント・ブローカは tppost(3c) を使用します。管理者もアプリケーション・プロセスもイベントをサブスクライブできます。
イベント・ブローカは、MIB オブジェクトの 100 種類以上の状態の変化をシステム・イベントとして認識します。ポストされたシステム・イベントは、イベントが発生した MIB オブジェクトの表現と、発生したイベントを識別するイベント固有のフィールドで構成されます。たとえば、マシンが分断された場合、ポストされるイベントには次の情報が含まれます。
システム・イベントにサブスクライブするだけで、イベント・ブローカを使用できます。
関連項目
ログ・ファイルを使用してアクティビティを監視する
エラー状況を迅速かつ正確に識別するため、BEA Tuxedo システムには次のログ・ファイルが用意されています。
これらのログ・ファイルの管理と更新は、アプリケーションの実行中に常に行われます。
関連項目
トランザクション・ログ (TLOG) とは
トランザクション・ログ (TLOG) には、コミット・フェーズのグローバル・トランザクションが記録されます。2 フェーズ・コミット・プロトコルのうち、第 1 フェーズの終了時に、グローバル・トランザクションのパーティシパントは、グローバル・トランザクションをコミットするか、またはロールバックするかを決める応答を発行します。この応答は、TLOG に記録されます。
TLOG ファイルを使用するのは、グローバル・トランザクションを調整するトランザクション・マネージャ・サーバ (TMS) だけです。管理者は参照しません。TLOG のロケーションとサイズは、UBBCONFIG ファイルの MACHINES セクションにある 4 つのパラメータで指定します。
グローバル・トランザクションに参加する各マシンに TLOG を作成する必要があります。
関連項目
ユーザ・ログ (ULOG) とは
ユーザ・ログ (ULOG) は、BEA Tuxedo システムによって生成されるすべてのメッセージ、つまりエラー・メッセージ、警告メッセージ、情報メッセージ、デバッグ・メッセージが書き込まれるファイルです。アプリケーションのクライアントおよびサーバも、ユーザ・ログへの書き込みが可能です。ログは毎日新しく作成されます。そのため、マシンごとにログが異なる場合もあります。ただし、リモート・ファイル・システムが使用されている場合、ULOG を複数のマシンで共有できます。
ULOG によって管理者に提供されるシステム・イベントの記録から、BEA Tuxedo システムおよびアプリケーションのほとんどの障害の原因を特定できます。ULOG はテキスト・ファイルなので、任意のテキスト・エディタで表示できます。ULOG には、tlisten プロセスによって生成されるメッセージも挿入されています。tlisten プロセスにより、アプリケーション内のほかのマシンにあるリモート・サービスに接続できます。マスタ・マシンを含め各マシンで tlisten プロセスが実行されていることが必要です。
ログを使用してエラーを検出する
BEA Tuxedo のログ・ファイルを使用して、アプリケーション・エラーおよびシステム・エラーを検出できます。
トランザクション・ログ (TLOG) を分析する
TLOG は、コミット処理中のグローバル・トランザクションに関するメッセージのみを含むバイナリ形式のファイルです。TLOG を表示するには、まずテキスト形式に変換する必要があります。BEA Tuxedo システムでは、tmadmin を使った 2 つの方法で TLOG を変換できます。
dumptlog コマンドおよび loadtlog コマンドは、サーバ・グループやマシンを移行するときに、マシン間で TLOG を移動する場合にも便利です。
トランザクション・エラーを検出する
MIB T_TRANSACTION クラスを使用して、システム内の実行時のトランザクション属性を取得できます。この情報は、tmadmin コマンドの printtrans (pt) を使用して表示することもできます。トランザクション内の各グループに関する情報は、tmadmin を冗長モードで実行した場合にのみ表示されます。冗長モードで実行するには、それ以前に verbose (v) コマンドを実行しておく必要があります。
トランザクションのコミット・プロセスの間に発生した重大なエラー (TLOG への書き込みの失敗など) は、USERLOG に書き込まれます。
ユーザ・ログ (ULOG) を分析する
BEA Tuxedo システムでは、アプリケーション内のアクティブなマシンにログ・ファイルが置かれます。このログ・ファイルには、BEA Tuxedo システムのエラー・メッセージ、警告メッセージ、デバッグ・メッセージ、またはそれ以外の役立つ情報が含まれています。このファイルをユーザ・ログ (ULOG) と呼びます。ULOG を使用すると、BEA Tuxedo ATMI によって返されるエラーを簡単に見つけることができます。また、ULOG は、BEA Tuxedo システムとアプリケーションで生成されたエラー情報の主要な格納先となります。
ULOG の情報を使用すると、システムやアプリケーションの障害の原因を特定できます。ユーザ・ログには、1 つの問題に対して複数のメッセージを記録できます。一般的には、先に記述されたメッセージの方が有益な診断情報を説明しています。
ULOG メッセージの例
次の例では、LIBTUX_CAT カタログのメッセージ 358 が、その後のメッセージで報告される問題の原因を説明しています。つまり、UNIX システム・セマフォの不足が、アプリケーションを起動できない原因であることを示しています。
コード リスト2-1 ULOG メッセージの例
151550.gumby!BBL.28041.1.0:LIBTUX_CAT:262: std main starting
151550.gumby!BBL.28041.1.0:LIBTUX_CAT:358: reached UNIX limit on semaphore ids
151550.gumby!BBL.28041.1.0:LIBTUX_CAT:248:fatal: system init function ...
151550.gumby!BBL.28040.1.0:CMDTUX_CAT:825: Process BBL at SITE1 failed ...
151550.gumby!BBL.28040.1.0:WARNING: No BBL available on site SITE1.
Will not attempt to boot server processes on that site.
注記 ユーザ・ログ・メッセージの詳細と、問題に対する適切な対応策については、『システム・メッセージ』を参照してください。
ULOG 内の tlisten メッセージを分析する
ULOG には、tlisten プロセスのエラー・メッセージも記録されます。tlisten プロセスのメッセージは、任意のテキスト・エディタを使用して表示できます。MASTER マシンを含む各マシン上で、個別に tlisten プロセスが実行されます。それぞれの tlisten プロセスのログは、各マシン上の ULOG に記録されますが、リモート・ファイル・システムから共有で使用することもできます。
ULOG は、tlisten プロセスのエラーを記録します。tlisten が使用されるのは、tmboot を使用してシステムを起動するとき、およびアプリケーションの実行中に tmadmin を実行するときです。tlisten のメッセージは、tlisten プロセスの実行後、直ちに作成されます。tlisten プロセスでエラーが発生すると、メッセージが ULOG に記録されます。
注記 アプリケーションの管理者には ULOG の tlisten メッセージを分析する責任がありますが、プログラマも ULOG のメッセージを活用できます。
BEA Tuxedo System Messages の「CMDTUX カタログ£には、tlisten のメッセージに関する次の情報が説明されています。
tlisten メッセージの例
ULOG 内の次の tlisten メッセージを例に取ります。
121449.gumby!simpserv.27190.1.0:LIBTUX_CAT:262:std main starting
ULOG のメッセージは、タグとテキストで構成されています。タグは、次の情報で構成されています。
注記 シングルスレッドおよびシングルコンテキストのアプリケーションの場合、thread_ID フィールドと context_ID フィールドにプレースホルダが出力されます。アプリケーションがマルチスレッドであるかどうかは、複数のスレッドを使用するまでわかりません。
テキストは、次の情報で構成されています。
注記 このメッセージについては、BEA Tuxedo System Messages の「LIBTUX カタログ」を参照してください。
関連項目
アプリケーション・サービス・ログを使用してサービスの作業負荷を予測する
BEA Tuxedo アプリケーション・サーバでは、処理対象のサービス要求のログを生成することができます。このログは、サーバの標準出力 (stdout) に表示されます。各レコードには、サービス名、開始時刻、および終了時刻が記録されます。
このログは、サーバの起動後に要求できます。txrpt 機能を使用してサーバの実行時間に関するサマリを生成し、ログの出力結果を分析できます。このデータを使用すると、サービスごとの相対的な作業負荷を見積もることができ、MIB 内の該当するサービスに対して作業負荷パラメータを適切に設定できます。
MIB を使用してアプリケーションを監視する
MIB を使用すると、2 種類の操作を実行できます。1 つ目は、get 操作を使用した MIB からの情報の取得です。2 つ目は、set 操作を使用した MIB の情報の更新です。これらの操作は、ATMI 関数 (tpalloc(3c)、tprealloc(3c)、tpcall(3c)、tpacall(3c)、tpgetrply(3c)、tpenqueue(3c)、tpdequeue(3c)など) を使用していつでも実行できます。
get 操作を使って MIB を照会すると、MIB は一致したオブジェクトをいくつか返し、そのほかの候補数を示します。MIB は、残りのオブジェクトを取得するためのハンドル (カーソル) を返します。次のオブジェクトのセットを取得する操作は、getnext です。照会したオブジェクトが複数のバッファに渡ると、3 つ目の操作が発生します。
制限を指定して MIB を照会する
仮想データベースである MIB を照会するとは、データベース・テーブルからレコードのセットを選択することです。データベース・テーブルのサイズを制限する方法は 2 つあります。つまり、照会に対して返すオブジェクト数を制限するか、または各オブジェクトの情報量を制限します。キー・フィールドとフィルタを使用して、リクエストの範囲を必要なデータだけに制限することもできます。制限を多く指定すればするほど、アプリケーションから要求される情報は少なくなり、応答は早くなります。
グローバル・データおよびローカル・データを照会する
MIB のデータは、いくつかの場所に分けて保存されています。分散アプリケーションでは、複数のマシンに複製されているデータもあります。また、複製はされず、データの属性やデータが表すオブジェクトにより、特定のマシンのローカル・データになるデータもあります。
グローバル・データとは
グローバル・データとは、サーバなどのアプリケーション・コンポーネントに関する情報で、アプリケーション内のすべてのマシン上に複製されます。サーバに関するほとんどのデータ (コンフィギュレーションや状態に関する情報など) は、アプリケーションにグローバルに複製され、特にすべての掲示板に複製されます。BEA Tuxedo アプリケーションでは、どこからでもこの情報にアクセスできます。
たとえば、管理者は、Customer Orders という名前のアプリケーション内の任意のマシンから、サーバ B6 が Group1 に属しており、CustOrdA というマシン上で起動しており、アクティブであることを確認できます。
ローカル・データとは
ローカル・データとは、グローバルには複製されない、エンティティに対してローカルなデータ (サーバの統計など) のことです。ローカルな属性の例は TA_TOTREQC です。この属性は、特定のサーバ上でサービスが処理される回数を定義します。この統計は、ホスト・マシン上のサーバに保存されます。サーバがサービス要求を受信し、そのサービスが処理されると、カウンタの値が増えます。この種の情報はローカルで管理されるため、複製するとシステムの性能が低下します。
MIB には、ローカル (クライアントなど) にしかないクラスもあります。クライアントがログインすると、掲示板にクライアント用のエントリが作成され、ここにクライアントに関するトラッキング情報が記録されます。MIB は、このエントリを調べることにより、いつでもクライアントの状態を判別できます。
tpadmcall を使用して情報にアクセスする
BEA Tuxedo システムには、アプリケーションが稼動していない場合に MIB に直接アクセスするためのプログラミング・インターフェイスが用意されています。これが tpadmcall 関数であり、MIB を構成するデータにアプリケーションから直接アクセスするときに使用します。tpadmcall を使用すると、ローカル情報のサブセットにアクセスできます。
tpadmcall は、システムが稼動していないときに、システムを照会したり、管理上の変更を行う場合に使用してください。tpadmcall は、リクエストを送信する代わりに TUXCONFIG ファイルを照会します。送信用と受信用のデータ・バッファ (照会と応答の内容を格納) は、まったく同じです。
関連項目
ud32 を使用して MIB の照会と更新を行う
ud32 は、BEA Tuxedo システムに付属のクライアント・プログラムであり、FML バッファ型のテキスト表現で構成される入力情報を読み込みます。ud32 は、MIB に対して特殊な照会を行ったり、MIB を更新するときに使用できます。ud32 を実行すると、FML32 バッファが作成され、バッファを指定したサービス呼び出しが行われます。サービス呼び出しに対する応答 (FML32 バッファ型) を受信すると、結果は画面上またはテキスト・ファイルに出力されます。 ud32 は、テキスト形式の FML フィールドと値を使用して FML32 型のバッファを作成し、バッファ内で指定されたサービスを呼び出して、応答を待ちます。応答は、レポートとして FML32 形式で返されます。MIB は FML32 をベースにしているため、ud32 は MIB のスクリプト作成用ツールになります。 たとえば、次のテキストを含む小さいファイルを作成するとします。 service name=.tmib and ta_operation=get, TACLASSES=T_SERVER ud32 にこのファイルを入力すると、サーバに関するすべてのシステム・データが一覧表示された FML 出力バッファが返されます。
実行時のトレース機能を使用する
BEA Tuxedo システムには、分散型ビジネス・アプリケーションの実行をトラッキングする実行時のトレース機能があります。システムには、さまざまなカテゴリの関数の呼び出しを記録するためのトレース・ポイントが組み込まれています。たとえば、アプリケーションによって発行された ATMI 関数、X/Open 準拠のリソース・マネージャに対する BEA Tuxedo システムからの XA 関数などです。
トレース機能を有効にするには、カテゴリ、フィルタ式、およびアクションを含むトレース式を指定する必要があります。カテゴリには、トレース対象の関数の種類 (ATMI など) を指定します。フィルタ式には、アクションをトリガした特定の関数を指定します。アクションには、BEA Tuxedo システムによって指定された関数に対する応答を指定します。たとえば、ULOG へのレコードの書き込み、システム・コマンドの実行、トレース処理の終了、などのアクションを指定できます。クライアント・プロセスでは、リクエストを使用してトレース機能を複製転送することもできます。この機能は「ダイイング」と呼ばれます。つまり、トレース処理により、クライアントから呼び出されたすべてのサービスを「色付けする」ことを意味します。
トレース式は、TMTRACE 環境変数を設定するか、またはサーバ環境で式を指定することにより設定できます。
tmadmin の changetrace コマンドを使用すると、トレース・オプションをアクティブにしたり非アクティブにできます。このコマンドを使用すると、アクティブなクライアント・プロセスまたはサーバ・プロセスのトレース式を上書きできます。管理者は、すべてのクライアントとサーバに対してグローバルなトレース機能を許可することも、特定のマシン、グループ、またはサーバだけがトレース機能を実行できるように設定することもできます。
関連項目
DBBL および BBL を使用してエラーを管理する
BEA Tuxedo システムでは、次の 2 つの管理サーバを使用して、掲示板にある情報をアプリケーション内のすべのマシンに分散します。
図 2-3 DBBL と BBL を使用した診断および修復
どちらのサーバにも障害を管理する役割があります。DBBL はアプリケーション内のほかのアクティブ・マシンの状態を調整します。各 BBL は、MIB の状態の変更についての通信を行い、不定期的に DBBL にホスト・マシン上のすべてが順調であることを示すメッセージを送信します。
BEA Tuxedo のランタイム・システムは、ユーザ・ログ (ULOG) にイベント (システム・エラー、警告、トレース・イベントも含む) を記録します。プログラマは、ULOG を使用して、アプリケーションをデバッグしたり、認可の失敗などの特別な状況や検出した状態を管理者に通知します。
ATMI を使用してシステム・エラーとアプリケーション・エラーを処理する
ATMI を使用すると、プログラマは通信に関するよりグローバルな問題を管理できます。ATMI には、アプリケーションとシステムの両方に関連するエラーを処理する機能があります。サービス・ルーチンで、アプリケーション・エラー (無効なアカウント番号が使用された場合など) が発生すると、アプリケーション・エラーが返され、サービスは実行されたがリクエストは完了しなかったことがクライアントに通知されます。
システム障害 (リクエストの実行中にサーバがクラッシュするなど) が発生すると、システム・エラーが返され、サービス・ルーチンによりタスクが実行されなかったことがクライアントに通知されます。BEA Tuxedo システムは、アプリケーションの動作およびシステム自体の動作を監視し、プログラムに対してシステム・エラーを発行します。
設定可能なタイムアウトのメカニズムを使用する
リクエストの処理中に、サービスが無限ループに陥る場合があります。この場合、クライアント側で待機しても応答は戻りません。クライアントが無限に待機しないようにするため、BEA Tuxedo システムには、ブロッキング・タイムアウトとトランザクション・タイムアウトという 2 つの設定可能なタイムアウトのメカニズムがあります。これらのタイムアウト・メカニズムの詳細については、『BEA Tuxedo Domains コンポーネント』のDomains のトランザクション・タイムアウトとブロッキング・タイムアウトの指定を参照してください。
ブロッキング・タイムアウトは、ブロックされたプログラムが、何らかのイベント発生後に指定の時間を超えて待機しないようにするメカニズムです。いったんタイムアウトが検出されると、待機中のプログラムは、ブロッキング・タイムアウトが発生したことを通知するシステム・エラーを受信します。ブロッキング・タイムアウトは、サービス要求の有効期間、つまりアプリケーションがサービス要求に対する応答を待機する時間を定義します。タイムアウト値は、TUXCONFIG ファイルの RESOURCES セクションの BLOCKTIME フィールドで定義されるグローバルな値です。
トランザクション・タイムアウトは、アクティブなトランザクションでリソースが集中することが原因で発生するタイムアウトです。トランザクション・タイムアウトは、トランザクション (その中で複数のサービス要求が行われる場合もあり) の有効期間を定義します。このタイムアウト値は、tpbegin(3c) を呼び出して、トランザクションを開始するときに定義されます。トランザクション・タイムアウトは、リソースを最大化する場合に便利です。たとえば、トランザクション処理中にデータベースがロックされた場合に、アプリケーションのトランザクション用のリソースが停止状態になる時間を制限することができます。トランザクション・タイムアウトは、常にブロッキング・タイムアウトを上書きします。
UBBCONFIG ファイルのトランザクション・ライムアウト・パラメータには次の 2 つがあります。
これらのトランザクション・タイムアウト・パラメータの詳細については、『ファイル形式、データ記述方法、MIB、およびシステム・プロセスのリファレンス』の UBBCONFIG(5) を参照してください。
冗長サーバを設定して障害を処理する
冗長サーバと自動再起動機能をアプリケーションに設定して、障害に対処することもできます。冗長サーバを設定すると、可用性が高まり、大量の処理、サーバ障害、またはマシン障害を処理できるようになります。BEA Tuxedo システムは、アクティブなサーバの状態を定期的に調べ、再起動可能なサーバの障害を検出すると、自動的にサーバの新しいインスタンスを生成します。
サーバに自動再起動のプロパティを設定すると、個々のサーバの障害を処理できます。また、システムによる再起動の回数を指定することもできます。この機能により、サーバの再起動回数の制限が原因で度々発生するアプリケーション・エラーを回避できます。
BEA Tuxedo システムは、アクティブなマシンの可用性を頻繁に調べます。マシンにアクセスできない場合は、そのマシンを「分断されたマシン (partitioned)」とマークします。この場合は、システム・イベントが生成されます。マシンの分断は、ネットワーク障害、マシン障害、またはサーバの性能低下が原因で発生する場合もあります。
関連項目
マルチスレッド化またはマルチコンテキスト化されたアプリケーションを監視する
したがって、プログラマは、プロセス内の個々のスレッドが異常終了した可能性があることを認識する必要があります。1 つのスレッドが異常終了してシグナルが出されると、通常、そのスレッドが属する全体のプロセスが異常終了しているため、BBL により異常終了が検出されます。
ただし、スレッドの exit 関数を誤って呼び出したためにスレッドが異常終了した場合、シグナルは生成されません。スレッドが tpterm() を呼び出す前にこの種の異常終了が発生すると、BBL では異常終了を検出できず、異常終了したスレッドに関連するコンテキストの登録テーブル・スロットの割り当ては解除されません(スレッドの異常終了を検出できても、BBL は通常この登録テーブルのスロットの割り当て解除は行いません。スレッドが異常終了すると別のスレッドがコンテキストに関連付けられる、というアプリケーション・モデルがあるためです)。
この制限事項には適切な対応策がないため、プログラマはこの点を考慮してアプリケーションを設計する必要があります。
MIB を使用してマルチスレッド化またはマルチコンテキスト化されたアプリケーションのデータを取得する
注記 ここで説明する機能は、使用する管理ツールに関係なく、マルチスレッド化またはマルチコンテキスト化されたすべてのアプリケーションに適用されます。ここでは、MIB の呼び出しを使用する管理者の観点で機能を説明しています。MIB 用のインターフェイス (tmadmin(1) または BEA Administration Console) を使用する管理者も適用できます。
マルチスレッド化またはマルチコンテキスト化されたアプリケーションのデータは、次の方法で取得できます。
取得した情報は、以下の場所に格納されます。
たとえば、12 のサーバ・ディスパッチ・スレッドが同時に実行されている場合、このアプリケーション用の MIB の T_SERVERCTXT クラスには、12 のオカレンスを含む TA_CONTEXTID フィールド、12 のオカレンスを含む TA_SRVGRP フィールド、などが設定されます。
T_SERVER クラス内のフィールドに複数のインスタンスがあり、これらのインスタンスの値がマルチコンテキスト化されたサーバのコンテキストごとに異なる場合、T_SERVER クラスのフィールドにはダミーの値が指定され、T_SERVERCTXT フィールドには、各コンテキストの実際の値が指定されます。
関連項目
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
