(57)【要約】【課題】サーバの処理速度低下の原因を特定する際のアプリケーションの負荷の軽減を図ることを目的とする。【解決手段】複数の処理を並列実行可能な情報処理装置は、第１の処理の排他制御による排他処理時間が所定時間を超えた場合、または該排他制御により待機させられた第２の処理の量が所定数を超えた場合に、前記第１の処理に関する呼び出し関係を示す情報を生成する排他制御部と、前記排他制御の終了後に実行される前記第２の処理によるハードウェア利用状況と、前記呼び出し関係を示す情報とを対応付けて記憶部に記憶する記憶制御部と、を含む。【選択図】図１
2018181131.tif 000002
【特許請求の範囲】
【請求項１】
複数の処理を並列実行可能な情報処理装置で実行される処理の監視プログラムであって、
第１の処理の排他制御による排他処理時間が所定時間を超えた場合、または該排他制御により待機させられた第２の処理の量が所定数を超えた場合に、前記第１の処理に関する呼び出し関係を示す情報を生成し、
前記排他制御の終了後に実行される前記第２の処理によるハードウェア利用状況と、前記呼び出し関係を示す情報とを対応付けて記憶部に記憶する、
処理を前記情報処理装置に実行させることを特徴とする監視プログラム。
【請求項２】
前記排他制御が終了したときから、一定時間経過後に、前記第２の処理によるハードウェア利用状況を出力する、
処理を前記情報処理装置に実行させることを特徴とする請求項１記載の監視プログラム。
【請求項３】
前記リソースの利用状況を、前記一定時間経過後、所定間隔ごとに出力する、
処理を前記情報処理装置に実行させることを特徴とする請求項２記載の監視プログラム。
【請求項４】
前記排他制御が終了したときから、前記一定時間経過後に、前記第１の処理の実行を開始する、
処理を前記情報処理装置に実行させることを特徴とする請求項２記載の監視プログラム。
【請求項５】
前記呼び出し関係を示す情報が出力された回数が所定の回数を超えると、該呼び出し関係を示す情報の出力を停止する、
処理を前記情報処理装置に実行させることを特徴とする請求項１乃至４のうち何れか１項に記載の監視プログラム。
【請求項６】
前記排他制御が行われる前記第１の処理の実行を監視するプログラムを業務アプリケーションプロセスに埋め込み、
前記業務アプリケーションプロセスを起動する際に、前記監視するプログラムの実行を開始させる、
処理を前記情報処理装置に実行させることを特徴とする請求項１乃至５のうち何れか１項に記載の監視プログラム。
【請求項７】
複数の処理を並列実行可能な情報処理装置で実行される処理の監視方法であって、
第１の処理の排他制御による排他処理時間が所定時間を超えた場合、または該排他制御により待機させられた第２の処理の量が所定数を超えた場合に、前記第１の処理に関する呼び出し関係を示す情報を生成し、
前記排他制御の終了後に実行される前記第２の処理によるハードウェア利用状況と、前記呼び出し関係を示す情報とを対応付けて記憶部に記憶する、
処理を前記情報処理装置が実行することを特徴とする監視方法。
【請求項８】
複数の処理を並列実行可能な情報処理装置であって、
第１の処理の排他制御による排他処理時間が所定時間を超えた場合、または該排他制御により待機させられた第２の処理の量が所定数を超えた場合に、前記第１の処理に関する呼び出し関係を示す情報を生成する排他制御部と、
前記排他制御の終了後に実行される前記第２の処理によるハードウェア利用状況と、前記呼び出し関係を示す情報とを対応付けて記憶部に記憶する記憶制御部と、
を備えることを特徴とする情報処理装置。
【請求項９】
業務アプリケーションの起動を行なう処理プログラムであって、
前記業務アプリケーションの起動を行うに際して、排他制御が行われるスレッドの実行を監視する監視プログラムを前記業務アプリケーションのプロセスに埋め込み、
前記監視プログラムが実行された後に、前記業務アプリケーションのプロセスの実行を開始する、
処理を情報処理装置に実行させることを特徴とする処理プログラム。
【請求項１０】
業務アプリケーションの起動を行なう処理方法であって、
前記業務アプリケーションの起動を行うに際して、排他制御が行われるスレッドの実行を監視する監視プログラムを前記業務アプリケーションのプロセスに埋め込み、
前記監視プログラムが実行された後に、前記業務アプリケーションのプロセスの実行を開始する、
処理を情報処理装置が実行することを特徴とする処理方法。
【請求項１１】
業務アプリケーションの起動を行うに際して、排他制御が行われるスレッドの実行を監視する監視プログラムを前記業務アプリケーションのプロセスに埋め込み、前記監視プログラムが実行された後に、前記業務アプリケーションのプロセスの実行を開始する起動制御部、
を備えることを特徴とする情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、監視プログラム、監視方法、処理プログラム、処理方法および情報処理装置に関する。
【背景技術】
【０００２】
サーバと複数のクライアント端末とが相互に通信を行うシステムにおいて、サーバが、複数のクライアント端末からリクエストを受信した場合、該サーバは、複数のリクエストに対して処理を行なう。例えば、サーバは、受信した複数のリクエストのそれぞれについてスレッドを生成し、複数のスレッドを並列的に処理する。
【０００３】
また、複数のスレッドのうち１つのスレッドが所定の資源を占有する場合、排他制御が行われる。該排他制御により、他のスレッドは、排他制御が終了するまで、待機させられる。
【０００４】
関連する技術として、複数のCentral Processing Unit(CPU)を備えるマルチＣＰＵにおける自システムの異常検出および検出した異常の自動復旧に関する技術が提案されている（例えば、特許文献１を参照）。
【０００５】
また、セマフォ等のソフトウェア資源に対する長い待ち時間を要因とするシステムの性能劣化に対して、その原因を特定する技術が提案されている（例えば、特許文献２を参照）。
【０００６】
また、複数のトランザクションを並行処理する際のボトルネックについて、その発生箇所の特定を可能とする技術が提案されている（例えば、特許文献３を参照）。
【０００７】
また、システムの運用環境に影響を与えずに性能ボトルネックと、その原因および位置を識別するためにデータ収集するシステムテスト方法に関する技術が提案されている（例えば、特許文献４を参照）。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】国際公開第２００８／１１１１２４号
【特許文献２】特開２００５−３３９４３７号公報
【特許文献３】特開２００６−２２７９９９号公報
【特許文献４】特表２０１３−５３３５５３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
例えば、運用中のサーバの負荷が高くなると、該サーバの処理速度が低下する。この場合、サーバの処理速度低下（スローダウン）の原因を特定する作業（原因特定作業）が行なわれる。
【００１０】
運用中のサーバでは、例えば、業務アプリケーションが動作している。業務アプリケーションが動作中に、スローダウンの原因特定作業が行なわれると、該原因特定作業に起因して、業務アプリケーションの負荷が高くなる。業務アプリケーションの負荷が高くなると、サーバの応答速度が低下するため、該負荷は、低減されることが好ましい。
【００１１】
スローダウンは、スレッドの排他制御によっても生じることがある。この場合、各スレッドが出力するコールスタック情報に基づいて、スローダウンの原因特定作業を行なうことが考えられる。
【００１２】
ただし、複数のスレッドが出力するコールスタック情報の情報量は多くなる。情報量が多いコールスタック情報に基づいてスローダウンの原因特定作業が行なわれると、該原因特定作業の負荷が高くなり、その結果、業務アプリケーションの負荷が高くなる。
【００１３】
１つの側面として、本発明は、サーバの処理速度低下の原因を特定する際のアプリケーションの負荷の軽減を図ることを目的とする。
【課題を解決するための手段】
【００１４】
１つの態様では、複数の処理を並列実行可能な情報処理装置で実行される処理の監視プログラムは、第１の処理の排他制御による排他処理時間が所定時間を超えた場合、または該排他制御により待機させられた第２の処理の量が所定数を超えた場合に、前記第１の処理に関する呼び出し関係を示す情報を生成し、前記排他制御の終了後に実行される前記第２の処理によるハードウェア利用状況と、前記呼び出し関係を示す情報とを対応付けて記憶部に記憶する、処理を前記情報処理装置に実行させる。
【発明の効果】
【００１５】
１つの側面によれば、サーバの処理速度低下の原因を特定する際のアプリケーションの負荷の軽減を図ることができる。
【図面の簡単な説明】
【００１６】
【図１】システムの全体構成の一例を示す図である。
【図２】排他に起因するスローダウンの一例を示す図である。
【図３】起動制御の一例を示す図（その１）である。
【図４】起動制御の一例を示す図（その２）である。
【図５】業務アプリケーションプロセス終了の一例を示す図である。
【図６】排他管理テーブルの遷移の一例を示す図（その１）である。
【図７】排他管理テーブルの遷移の一例を示す図（その２）である。
【図８】排他制御終了時における排他管理テーブルの一例を示す図である。
【図９】一定時間経過後にハードウェア利用率の取得を行う一例を示す図である。
【図１０】排他管理テーブルの一例を示す図である。
【図１１】初期設定テーブルの一例を示す図である。
【図１２】ハードウェア利用率情報の一例を示す図（その１）である。
【図１３】ハードウェア利用率情報の一例を示す図（その２）である。
【図１４】コールスタック情報の一例を示す図である。
【図１５】起動モジュールプロセスの処理の流れの一例を示すフローチャートである。
【図１６】排他監視スレッドの処理の流れの一例を示すフローチャートである。
【図１７】業務処理の流れの一例を示すフローチャートである。
【図１８】排他監視スレッド初期化処理の流れの一例を示すフローチャートである。
【図１９】排他監視スレッドの処理の流れの一例を示すフローチャート（その１）である。
【図２０】排他監視スレッドの処理の流れの一例を示すフローチャート（その２）である。
【図２１】排他区間開始関数の流れの一例を示すフローチャートである。
【図２２】排他区間終了関数の流れの一例を示すフローチャート（その１）である。
【図２３】排他区間終了関数の流れの一例を示すフローチャート（その２）である。
【図２４】サーバのハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【００１７】
＜実施形態のシステムの一例＞
以下、図面を参照して、実施形態について説明する。図１は、実施形態のシステム１の一例である。システム１において、サーバ２と、クライアント端末３（３Ａ、３Ｂ、３Ｃ、・・・）とは、ネットワークを介して、接続される。
【００１８】
クライアント端末３とサーバ２とは相互に通信を行なう。クライアント端末３は、パーソナルコンピュータやタブレット端末等の任意の端末であってよい。
【００１９】
サーバ２は、例えば、業務サーバであり、クライアント端末３からのリクエストに対して、所定の処理を行い、該リクエストの送信元のクライアント端末３に対して、レスポンスを返す。上記処理の処理は、例えば、業務に関する処理である。
【００２０】
サーバ２は、クライアント端末３からのリクエストを受信すると、該リクエストについてのスレッドを生成する。スレッドは、第１の処理および第２の処理の一例である。実施形態では、サーバ２が、複数のクライアント端末３からリクエストを同時期に受信するケースを想定する。
【００２１】
サーバ２が複数のクライアント端末３から、同時期にリクエストを受信すると、サーバ２は、複数のスレッドを生成し、該複数のスレッドを並列的に処理する。そして、サーバ２は、処理結果をレスポンスとして、リクエスト送信元である各クライアント端末３に送信する。
【００２２】
図１の例に示されるように、サーバ２は、処理部１１と起動制御部１２と排他制御部１３と記憶制御部１４と通信部１５と記憶部１６とを含む。処理部１１と起動制御部１２と排他制御部１３とは、サーバ２のOperating System(OS)上で動作する所定のプログラムにより実現されてもよい。
【００２３】
処理部１１は、サーバ２で動作する所定のソフトウェア（以下、業務アプリケーション）に関するプロセスやスレッドに応じた処理を行なう。実施形態では、プロセス内で複数のスレッドが実行されるものとする。プロセスやスレッドの動作は、処理部１１の動作に対応する。
【００２４】
起動制御部１２は、業務アプリケーションの起動制御を行う。実施形態では、クライアント端末３から受信したリクエストに基づいて、起動制御部１２は、業務アプリケーションプロセスを起動する。以下、起動制御部１２を、起動モジュールプロセスと称することある。
【００２５】
排他制御部１３は、スレッドの排他制御を行なう。例えば、複数のスレッドのうち１つのスレッドが、所定の資源を占有したとする。この場合、排他制御部１３は、他のスレッドが該所定の資源へアクセスすることを規制する。以下、排他制御部１３を、排他監視スレッドと称することがある。該排他監視スレッドは、監視プログラムの一例である。
【００２６】
記憶制御部１４は、プロセス内で動作するスレッドまたは排他監視スレッドが出力する調査ログを記憶部１６に記憶する制御を行う。通信部１５は、各クライアント端末３と通信を行う。記憶部１６は、各種の情報を記憶する。例えば、記憶部１６は、上記の調査ログを記憶する。
【００２７】
＜排他に起因するスローダウンの一例＞
図２の例を参照して、排他に起因するスローダウンの一例について説明する。サーバ２のＣＰＵやメモリ等のハードウェア利用率が高くなると、サーバ２の負荷が高くなり、サーバ２の処理速度が低下する。該処理速度が低下すると、クライアント端末３がリクエストをサーバ２に送信してから、該クライアント端末３がレスポンスを受信するまでの時間が長くなる。つまり、サーバ２の応答速度が低下する。
【００２８】
サーバ２の処理速度の低下（以下、スローダウン）が生じると、サーバ２で動作している業務アプリケーションの応答速度も低下する。従って、スローダウンが生じた場合、該スローダウンの原因を特定する作業（原因特定作業）が行なわれる。該原因特定作業は、例えば、サーバ２が行なう。
【００２９】
例えば、サーバ２のハードウェア利用率が所定の閾値を超えた場合に、該サーバ２が、エラーログを出力し、該エラーログに基づいて、原因特定作業を行なうことが考えられる。
【００３０】
スローダウンは、スレッドの排他制御に起因する場合もある。複数のスレッドのうち１つのスレッドが所定の資源を占有すると、他のスレッドが、該所定の資源にアクセスすることが規制される。これにより、排他制御が行われる。
【００３１】
１つのスレッドが所定の資源を占有している場合、該１つのスレッドが所定の資源を解放するまで、他のスレッドは、待機させられる。上記１つのスレッドが所定の資源を占有している間、他のスレッドは待機しているため、サーバ２のハードウェア利用率が高くなる可能性は低い。従って、排他に起因するスローダウンを検出することが難しい。
【００３２】
一方、上記１つのスレッドが、所定の資源を解放した後、待機させられていた複数の他のスレッドがほぼ同じタイミングで実行されると、ハードウェア利用率が高くなり、スローダウンを生じる可能性がある。
【００３３】
例えば、図２に示されるように、排他（Ｘ）で排他制御される区間Ａ（排他区間Ａ）および区間Ｂ（排他区間Ｂ）があるとする。排他区間は、例えば、プログラムのソースコードのうち、複数の命令により構成される一群の処理である。
【００３４】
以下、スレッドが排他区間の処理の実行を開始してから、該排他区間の処理を終了するまでの時間（排他処理時間）を、排他処理期間と称することがある。
【００３５】
図２の例において、排他区間Ａに続く処理に、ハードウェアの利用率が高い処理があるとする。また、排他区間Ｂに、処理時間を長くする問題（バグ）があるとする。例えば、該バグは、排他区間で実施する必要がなく、かつ、外部状況によりレスポンスが悪化、またはエラーとなる通信やファイルアクセス等を実行している場合である。
【００３６】
図２の例において、スレッド１が、排他区間Ｂの処理の実行を開始したとする。この場合、スレッド１が資源（Ｒ）を占有するため、排他制御が行われる。従って、スレッド２〜４が排他区間Ａの処理を実行することは規制される。このため、スレッド１が資源（Ｒ）を解放するまで、スレッド２〜４は待機させられる。
【００３７】
図２の例におけるスレッド１（排他処理を実行しているスレッド）は、第１の処理の一例であり、スレッド２〜４（排他待ちしているスレッド）は、第２の処理の一例である。
【００３８】
スレッド１が、排他区間Ｂの処理を実行している際に、例えば、通信エラーが生じたとする。この場合、スレッド１が資源（Ｒ）を占有している時間は長くなる。スレッド１が資源（Ｒ）を占有している時間が長くなると、待機する他のスレッドの数が多くなる可能性がある。
【００３９】
図２の例では、スレッド１が資源（Ｒ）を占有している間、スレッド２〜４が待機させられる。従って、スレッド２〜４の待機時間は長くなるが、スレッド２〜４は、待機状態にあるため、サーバ２のハードウェア利用率は低い。
【００４０】
スレッド１が、排他区間Ｂの処理を終了すると、資源（Ｒ）が解放される。スレッド２〜４は、順番に、排他区間Ａの処理を実行する。上述したように、排他区間Ａに続く処理は、ハードウェアの利用率が高い。
【００４１】
従って、スレッド２〜４は、ハードウェアの利用率が高い処理（高負荷な処理）を並列的に実行する。ハードウェアの利用率が高い処理が並列的に実行されることで、スローダウンが生じる。
【００４２】
上記の場合、スレッド１が資源（Ｒ）を占有し、スレッド１の実行時間が長くなることに起因して、待機するスレッドの数が増える。そして、待機させられたスレッド２〜４により、ハードウェア利用率が高い処理が並列的に実行されることにより、スローダウンが生じる。
【００４３】
従って、スローダウンの一次的な原因は、排他（Ｘ）にある。この場合、ＣＰＵやメモリ等のハードウェア利用率に関するエラーログから、スローダウンの一次的な原因である排他（Ｘ）を特定することは難しい。
【００４４】
例えば、各スレッド１〜４がコールスタック情報を記憶部１６に所定間隔ごとに出力し、記憶部１６に記憶されたコールスタック情報に基づいて、スローダウンの原因を特定することが考えられる。コールスタック情報は、呼び出し関係を示す情報の一例である。
【００４５】
例えば、各スレッド１〜４が、短い時間間隔で出力したコールスタック情報に基づいて、スローダウンの原因を特定する場合、排他（Ｘ）に起因するスローダウンが特定される可能性がある。
【００４６】
コールスタック情報は、排他（Ｘ）で実行された関数の呼び出し関係を示し、該コールスタック情報を分析することで、排他（Ｘ）のうち何れの箇所がスローダウンを引き起こしたかを特定することができる。
【００４７】
ただし、上記の場合、短い時間間隔で多くのスレッドがコールスタック情報を生成して、出力するため、コールスタック情報の情報量は多くなり、その結果、スローダウンの原因を特定するための作業による負荷が高くなる。サーバ２では、業務アプリケーションが動作しているため、スローダウンの原因特定の負荷が高くなると、業務アプリケーションの負荷も高くなる。
【００４８】
実施形態では、排他制御による排他処理期間が所定時間を超えた場合、または上記排他制御により、待機させられたスレッドの数が所定数を超えた場合に、排他監視スレッドが、スレッド１についてのコールスタック情報を調査ログに出力する。記憶制御部１４は、出力された調査ログを記憶部１６に記憶する。
【００４９】
従って、複数のスレッドのうち、排他（Ｘ）の処理を実行していたスレッド１についてのコールスタック情報だけが出力されるため、コールスタック情報の情報量（調査ログの情報量）が少なくなる。このため、スローダウンの原因特定作業の負荷も低減する。また、コールスタック情報を記憶する記憶部１６の記憶量も低減できる。
【００５０】
＜起動制御の一例＞
図３乃至図５は、業務アプリケーションを起動する際の処理の一例を示す。例えば、サーバ２が、クライアント端末３から、業務アプリケーションを起動するリクエストを受信したとする。
【００５１】
該リクエストに応じて、起動モジュールプロセス（起動制御部１２）が実行される。起動モジュールプロセスは、業務アプリケーションのプロセス（以下、業務アプリケーションプロセス）を起動する制御を行う。この際、起動モジュールプロセスは、業務アプリケーションプロセスをサスペンド状態で起動する。
【００５２】
起動モジュールプロセスは、例えば、排他監視Dynamic Link Library(DLL)を呼び出し、排他監視スレッドを、サスペンド中の業務アプリケーションプロセスに埋め込む。排他監視スレッドは、排他制御部１３により実現される。
【００５３】
排他監視スレッドは、初期化処理を実行する。該初期化処理は、排他管理テーブルの初期化処理、ＯＳの排他Application Programming Interface(API)をラップ化する処理およびコールスタック情報を出力する例外ハンドラの登録処理を含む。
【００５４】
排他管理テーブルは、排他監視スレッドがスレッドの排他制御を行う際に用いられるテーブルである。排他監視スレッドは、初期化処理を実行する際に、排他管理テーブルの初期化を行なう。これにより、業務アプリケーションプロセスの実行が開始された後、初期化された排他管理テーブルが用いられる。
【００５５】
排他ＡＰＩは、例えば、排他区間を開始する関数（排他区間開始関数）および排他区間を終了する関数（排他区間終了関数）を含む。排他ＡＰＩがラップ化されることで、該排他ＡＰＩを汎用的に用いることができる。例えば、ラップ化された排他ＡＰＩに、所定の処理を追加することができる。ラップ化されていない排他ＡＰＩをオリジナルの排他ＡＰＩと称する。
【００５６】
リクエストに応じて生成されるスレッド（以下、レスポンダスレッドと称することがある）が、排他区間の処理を実行している際、所定の条件が満たされると、排他区間の処理を実行しているスレッドは、コールスタック情報を生成し、出力する。
【００５７】
図４に示されるように、排他監視スレッドの初期化処理が完了すると、排他監視スレッドは、起動モジュールプロセスに、初期化完了通知を出力し、サスペンドしていた業務アプリケーションプロセスの実行が開始する。
【００５８】
業務アプリケーションプロセスの実行が開始すると、該業務アプリケーションプロセスは、メインスレッドを実行する。メインスレッドは、業務アプリケーションプロセス全体を制御するスレッドであり、該メインスレッドが起動することにより、業務アプリケーションプロセスが稼動する。
【００５９】
サーバ２が、各クライアント端末３からリクエストを受信すると、業務アプリケーションプロセスは、リクエストに応じたスレッド（レスポンダスレッド）を生成し、該レスポンダスレッドに応じた処理を行なう。
【００６０】
図４の例に示されるように、起動モジュールプロセスが、初期完了通知を受け取ると、該起動モジュールプロセスは、自身のプロセスを終了する処理を行なう。これにより、起動モジュールプロセスの負荷がなくなり、サーバ２全体の負荷軽減が図られる。
【００６１】
起動モジュールプロセスが、業務アプリケーションプロセスを起動する際に、排他監視スレッドを業務アプリケーションプロセスに埋め込み、排他監視スレッドが、初期化処理を行なう。上記埋め込みは、インジェクションとも称される。
【００６２】
従って、排他監視スレッドは、初期状態から、業務アプリケーションプロセスのスレッド（レスポンダスレッド）の排他制御に関する情報を認識できる。
【００６３】
運用中の業務アプリケーション（実行中の業務アプリケーションプロセス）に、排他監視スレッドを埋め込むと、該排他監視スレッドは、実行中のスレッドの排他監視を行なう。このため、排他に起因したスローダウンの特定が正常に行なわれない可能性がある。
【００６４】
一方、上述したように、起動モジュールプロセスが、排他監視スレッドを、初期状態の業務アプリケーションに埋め込むことで、排他に起因したスローダウンの特定を正常に行うことができる。
【００６５】
また、起動モジュールプロセスが、排他監視スレッドを業務アプリケーションプロセスに埋め込むことで、業務アプリケーションプロセス自体に対する変更を要しなくなる。つまり、既存の業務アプリケーションに対して変更を行なう必要がない。
【００６６】
また、排他監視スレッドは、業務アプリケーションプロセスの中に埋め込まれる。従って、排他監視スレッドは、業務アプリケーションプロセスの中に存在するスレッド（レスポンダスレッド）の排他処理を監視することができる。
【００６７】
例えば、サーバ２が、プロセス間の排他処理を監視する機能を有している場合、該機能を用いて、プロセス間の排他に起因したスローダウンの特定を行うことができる。しかし、上記の機能は、プロセス間の排他処理を監視する機能であるため、業務アプリケーションプロセスの中のスレッドの排他処理を監視することは難しい。
【００６８】
実施形態では、起動モジュールプロセスが、排他監視スレッドを業務アプリケーションプロセスに埋め込むことで、該排他監視スレッドは、業務アプリケーションの中のスレッドの排他処理を監視することができる。
【００６９】
図５は、業務アプリケーションプロセス終了の一例を示す。業務アプリケーションプロセスが終了する際に、業務アプリケーションプロセスは、メインスレッドを終了させる。排他監視スレッドは、業務アプリケーションプロセスに、他のスレッドが存在しないことを確認した後に、自身のスレッドを終了する。これにより、業務アプリケーションプロセスが終了する。
【００７０】
＜排他制御開始時および排他制御終了時の一例＞
次に、排他制御開始時の処理について、説明する。図６および図７は、排他制御開始時における排他管理テーブルの遷移の一例を示す。業務アプリケーションプロセスのスレッド（レスポンダスレッド）が、排他区間の処理を実行すると、ラップ化された排他ＡＰＩが呼び出される。スレッドは、ラップ化された排他ＡＰＩに基づいて、排他管理テーブルの内容を更新する。
【００７１】
排他管理テーブルは、排他名と排他処理中と排他待ちリストと排他待ちエラー数とコールスタック出力数との項目（フィールド）を含む。排他名は、排他処理の名称を示す。排他処理中は、排他処理を行なっているスレッドに関する情報（排他情報セット）を示す。
【００７２】
実施形態では、排他情報セットは、スレッドを特定するスレッドIdentification(ID)と開始日時とタイムアウト時間との情報を含む。スレッドＩＤは、スレッドを識別するための固有の情報である。
【００７３】
例えば、業務アプリケーションプロセスが、レスポンダスレッドを生成した場合、生成されたレスポンダスレッドに固有のスレッドＩＤを付与してもよい。また、メインスレッドおよび排他監視スレッドにも、固有のスレッドＩＤが付与される。
【００７４】
開始日時は、スレッドが排他処理を開始した日時を示す。タイムアウト時間は、スレッドが排他を獲得する場合のタイムアウト時間を示す。排他管理テーブルのうち、排他待ちリストは、他のスレッドが排他処理を行っている際に排他待ちをしているスレッドに関する排他情報セットを記録するための項目である。
【００７５】
上述したように、排他待ちを行なっていたスレッドの待機時間がタイムアウト時間を超えた場合、排他待ちを行っていたスレッドは、排他待ちエラーとなる。排他管理テーブルのうち排他待ちエラー数は、排他待ちエラーとなったスレッドの数を記録するための項目である。コールスタック出力数は、コールスタック情報が出力された回数を示す。
【００７６】
例えば、業務アプリケーションプロセスが起動した後、排他制御が行われていなければ、排他管理テーブルには情報が記録されていない。図６の例において、スレッド１が排他区間の処理の実行を開始したとする。
【００７７】
スレッド１は、自身のスレッドＩＤを取得する。図６の例では、スレッド１のスレッドＩＤは、「１」である。スレッドが、排他区間の処理の実行を開始すると、排他ＡＰＩ（ラップ化された排他区間開始関数）が呼び出される。排他名は、例えば、排他区間開始関数の引数に基づいて、特定される。図６の例では、排他名は「Ａ」であるとする。
【００７８】
スレッド１は、排他管理テーブルのうち、排他名に「排他Ａ」を記録し、排他待ちリストに、排他情報セットを記録する。排他情報セットのうち、開始日時は、スレッド１が排他Ａの処理を開始した際に、例えば、ＯＳの機能により取得されてもよい。
【００７９】
また、スレッドごとに、予めタイムアウト時間が設定されていてもよい。なお、該タイムアウト時間は、無限大に設定されることがある。タイムアウト時間が無限大に設定されている場合、他のスレッドに対して排他が開放されない。
【００８０】
図６の例において、スレッド１が排他Ａの排他処理を開始する場合、排他管理テーブルの排他待ちリストには、スレッド１の排他情報セットが記録される。「ＴＩＤ１」はスレッドＩＤが「１」であることを示す。開始日時は「Ｔ１」であり、タイムアウト時間は「３０秒」である。
【００８１】
図６の例では、排他処理中に排他情報セットは記録されていない。つまり、排他Ａの排他処理を実行しているスレッドはない。この場合、スレッド１は、排他待ちリストの排他情報セットを、排他処理中に移動する。この際、上記排他情報セットの開始日時は「Ｔ１」から僅かな時間が経過後の日時としてもよい。
【００８２】
スレッドが排他処理を開始する際、オリジナルの排他区間開始関数が呼び出される。図６の例の場合、スレッド１が排他Ａの排他処理を実行する際、他のスレッドは、排他Ａの排他処理を実行していない。従って、スレッド１による排他Ａのオリジナルの排他区間開始関数の呼び出しは成功する。
【００８３】
図７の例において、スレッド１が排他Ａの処理を実行する際、既に、スレッド２（スレッドＩＤ＝２）が、排他Ａの処理を実行している。このため、排他管理テーブルのうち排他処理中に、スレッド２の排他情報セットが記録されている。
【００８４】
スレッド１が、排他Ａの処理を実行する際、該スレッド１は、排他待ちリストに、スレッド１の排他情報セットを記録する。スレッド２の排他情報セットで示されるタイムアウト時間は「３０秒」である。スレッド１の排他情報セットが排他待ちリストに記録されると、スレッド１は、オリジナルの排他区間開始関数を呼び出そうとする。
【００８５】
しかし、スレッド２が排他Ａの排他処理を実行しているため、スレッド１は、待機させられる。スレッド１の待機時間が、排他処理中の排他情報セットにおけるタイムアウト時間を超えた場合、スレッド１は、排他待ちエラーとして取り扱われる。この場合、スレッド１によるオリジナルの排他区間開始関数の呼び出しは失敗する。
【００８６】
スレッド１が排他待ちエラーとなると、排他管理テーブルのうち、排他待ちリストに記録されている排他情報セットが削除される。また、排他待ちエラー数がインクリメントされる。
【００８７】
次に、排他制御終了時の処理について説明する。図８は、排他制御終了時における排他管理テーブルの一例を示す。図８の例において、スレッド１（スレッドＩＤ＝１）が排他Ａの処理を実行している。
【００８８】
スレッド１が排他Ａの処理を終了する際、排他待ちリストには、スレッド２（スレッドＩＤ＝２）、スレッド３（スレッドＩＤ＝３）およびスレッド４（スレッドＩＤ＝４）の排他情報セットが記録されているとする。また、排他待ちエラー数は「５」であり、コールスタック出力数は「３」であるとする。
【００８９】
スレッド１が排他Ａの処理を終了すると、ラップ化された排他区間終了関数が呼び出される。そして、ラップ化された排他区間終了関数に基づいて、スレッド１は、排他管理テーブルのうち排他Ａのレコードを取得する。記憶制御部１４は、取得されたレコードを、記憶部１６の所定領域に記憶する。
【００９０】
また、スレッド１は、排他管理テーブルの排他Ａに対応するレコードのうち、排他名以外の情報を削除する。そして、オリジナルの排他区間終了関数が呼び出される。
【００９１】
オリジナルの排他区間終了関数が呼び出されると、スレッド１は、該オリジナルの排他区間終了関数に応じた処理を行う。スレッド１は、所定条件が満たされている場合、ハードウェア利用率を取得する。例えば、ＯＳの機能がＣＰＵやメモリ等のハードウェアの利用率を監視している場合、スレッド１は、上記ＯＳの機能から、ハードウェア利用率を取得してもよい。
【００９２】
スレッド１は、該スレッド１が排他区間の処理をしたときから、一定時間経過後に、上記ハードウェア利用率を取得する。排他区間を終了したスレッド１は、排他区間の終了後、一定時間経過するまで、待機する。その後、スレッド１の実行が開始される。これにより、スレッド１が排他区間の処理を終了したときから、一定時間経過後に、ハードウェア利用率が取得される。
【００９３】
スレッド１は、ハードウェア利用率を所定間隔ごとに取得し、取得されたハードウェア利用率を、スレッド１が実行していた排他に関する情報（記憶部１６の所定領域に記憶された排他管理テーブルのレコード）と共に、調査ログに出力する。記憶制御部１４は、該調査ログを記憶部１６に記憶する。
【００９４】
例えば、スレッド１が排他区間Ａの処理を実行した場合、スレッド１は、排他管理テーブルのうち排他Ａに対応するレコード（対応レコード）と共に、ハードウェア利用率を調査ログに出力する。該調査ログは、記憶部１６に記憶される。
【００９５】
図９の例に示されるように、スレッド１が排他（Ｘ）の区間Ｂの処理を実行している間、排他制御により、他のスレッドは待機させられる。例えば、通信エラー等により、スレッド１が排他（Ｘ）を占有している時間が長くなると、待機するスレッド数は多くなる。図９の例では、スレッド２〜４が、排他制御により待機させられる。
【００９６】
一方、スレッド２〜４は、排他（Ｘ）の区間Ａの処理の後、ハードウェアの利用率が高い処理を実行する。従って、スレッド２〜４が、ハードウェアの利用率が高い処理を並列的に実行することにより、サーバ２のハードウェアの利用率が高くなる。
【００９７】
ここで、スレッド１が排他（Ｘ）の区間Ｂの処理を実行した直後は、スレッド２〜４が、ハードウェアの利用率が高い処理を実行していない可能性が高い。図９の例に示されるように、スレッド２〜４の順番で、順次、ハードウェアの利用率が高い処理の実行が開始される。
【００９８】
従って、ハードウェアの利用率の取得は、スレッド１が排他（Ｘ）の区間Ｂの処理を実行した後、一定時間経過後に、行われる。これにより、スローダウンの原因が、スレッド１の排他制御であることが特定される。
【００９９】
＜排他監視スレッドの処理の一例＞
次に、図１０を参照して、排他監視スレッドの処理の一例について説明する。排他監視スレッドは、排他管理テーブルを参照して、排他処理中のスレッドの排他処理時間（排他処理期間）が所定時間以上である排他（排他名）を特定する。排他処理時間は、排他情報セットの開始日時から現在日時までの時間を示す。
【０１００】
排他監視スレッドは、排他処理中の上記排他処理時間が、タイムアウト時間（排他処理中のタイムアウト時間）に対する所定割合（Ｖ１％とする）以上（所定時間以上）である排他がある場合、コールスタック情報を出力させる例外を発行する。排他処理時間が長いスレッドの排他は、スローダウンを引き起こしている可能性がある。
【０１０１】
また、排他監視スレッドは、排他待ちリストのスレッドの排他待ち時間が、タイムアウト時間に対する所定割合（Ｖ２％とする）以上のスレッド数と、排他待ちエラー数との合計が所定数（Ｖ３とする）を超えている排他があるかを判定する。該排他がある場合、排他監視スレッドは、コールスタック情報を出力させる例外を発行する。
【０１０２】
排他待ちリストのスレッドの排他待ち時間が長くなると（Ｖ２％以上になると）、該スレッドは、スローダウンの原因となる可能性がある。また、排他待ち時間が長いスレッド数および排他待ちエラー数（長待機スレッド数）が多くなると、スローダウンの原因となる可能性がある。
【０１０３】
排他監視スレッドが、コールスタック情報を出力させる例外を発行する場合、排他監視スレッドは、排他処理を実行しているスレッドに対して、例外を転送する。排他監視スレッドには、コールスタック情報を出力させる例外ハンドラが登録されており、上記スレッドは、転送された例外に基づいて、例外ハンドラを呼び出す。
【０１０４】
上記スレッドは、例外ハンドラを呼び出すことにより、コールスタック情報を調査ログに出力する。記憶制御部１４は、調査ログを記憶部１６に記憶する。
【０１０５】
図１０の例において、排他Ａ〜Ｃのうち、排他Ｂを実行しているスレッド７に対してだけ、コールスタック情報を出力する例外が発行されたとする。この場合、複数のスレッドのうち、スレッド７についてのコールスタック情報だけが出力されるため、コールスタック情報の出力負荷が低減される。
【０１０６】
また、サーバ２が、記憶部１６に記憶されたコールスタック情報を参照して、スローダウンの分析（原因特定作業）を行う場合、コールスタック情報の情報量が多いと、原因特定作業の負荷が高くなる。
【０１０７】
実施形態では、上述したように、所定の条件を満たす排他を実行しているスレッドについてのコールスタック情報だけが出力されるため、少ない情報量のコールスタック情報に基づいて、スローダウンの原因特定作業を行うことができる。また、記憶部１６に記憶されるコールスタック情報の情報量を低減できる。
【０１０８】
また、実施形態では、コールスタック情報の出力数に上限を設けている。コールスタックの出力数が多くなると、スローダウンの原因特定作業の負荷が大きくなるため、コールスタックの出力数に上限を設けることで、スローダウンの原因特定作業の負荷の軽減が図られる。
【０１０９】
＜初期設定テーブルの一例＞
次に、図１１を参照して、初期設定テーブルの一例を示す。初期設定テーブルは、各種の判定の際に用いられる閾値（設定値）を示す。該初期設定テーブルは、記憶部１６に記憶される。上述した排他監視スレッドの初期化処理の際に、排他監視スレッドは、記憶部１６から、初期設定テーブルの各設定値を取得する。
【０１１０】
設定値Ｖ１〜Ｖ３は、上述した設定値である。設定値Ｖ４〜Ｖ７については、後述する。設定値Ｖ１〜Ｖ７は、任意の値に設定されてもよい。
【０１１１】
＜ハードウェア利用率情報の一例＞
次に、図１２および図１３を参照して、ハードウェア利用率情報の一例について説明する。上述したように、排他区間の処理を終了したスレッドは、一定時間経過後、所定間隔ごとにハードウェア利用率を示す情報（ハードウェア利用率情報）を調査ログに出力する。記憶制御部１４は、該調査ログを記憶部１６に記憶する。
【０１１２】
図１２の例は、スレッド１９０（スレッドＩＤ＝１９０）についてのハードウェア利用率情報を示す。ハードウェア利用率情報は、スレッドＩＤを含む。図１２の例に示されるように、ログ４−２−２以降のＣＰＵ利用率は、１００％になっている。
【０１１３】
排他管理テーブルには、スレッド１９０（スレッドＩＤ＝１９０）に対応する排他が記録されている。また、コールスタック情報にもスレッドＩＤが記録されている。スレッドＩＤにより、ハードウェア利用率情報とコールスタック情報とが対応付けられているため、排他に起因したスローダウンが特定される。
【０１１４】
図１３の例は、スレッド１９０（スレッドＩＤ＝１９０）についてのハードウェア利用率情報についての他の例を示す。図１３の例に示されるハードウェア利用率情報は、ＣＰＵ利用率は２０％から変化がない。従って、サーバ２にスローダウンが生じていないことを認識することがされる。
【０１１５】
＜コールスタック情報の一例＞
図１４を参照して、コールスタック情報の一例について説明する。コールスタック情報は、スレッドについての、関数の呼び出し関係を示す。コールスタック情報は、スレッドＩＤを含む。図１４の例のコールスタック情報は、スレッド１９０（スレッドＩＤ＝１９０）についての、コールスタックを示す。
【０１１６】
図１４の例のコールスタック情報のうち、関数４１以外の関数は、同じである。一方、該コールスタック情報のうち、ログ１−２に対応する関数４１の実行位置（命令列）は「１４０４」である。
【０１１７】
ログ２−２は、ログ１−２より後のコールスタック情報であり、ログ２−２に対応する関数４１の実行位置は「１４１４」である。ログ３−２は、ログ２−２より後のコールスタック情報であり、ログ３−２に対応する関数４１の実行位置は「１４０４」である。
【０１１８】
図１４の例に示されるコールスタック情報は、スレッドＩＤ（１９０）を含む。また、上述したように、ハードウェア利用率情報もスレッドＩＤ（１９０）を含む。記憶制御部１４は、スレッドＩＤ（１９０）を含むコールスタック情報およびハードウェア利用率情報を、調査ログとして、記憶部１６に記憶する。
【０１１９】
従って、記憶制御部１４は、スレッドＩＤにより対応付けられたコールスタック情報とハードウェア利用率情報とを、調査ログとして、記憶部１６に記憶する。該調査ログには、スレッドが実行中の排他に対応するレコードが含まれてもよい。
【０１２０】
例えば、図１４の例におけるコールスタック情報のうち、ログ１−２およびログ３−２と、ログ２−２とでは、関数４１の実行位置が異なる。つまり、関数４１のうち実行位置「１４０４」〜「１４１４」に、排他に起因するスローダウンを生じた原因があることが特定される。
【０１２１】
従って、サーバ２で業務アプリケーションの運用中に、排他に起因するスローダウンを生じる問題箇所の特定がされる。
【０１２２】
＜実施形態の処理の流れの一例＞
次に、実施形態の処理の流れについて説明する。図１５は、起動モジュールプロセスの処理の流れの一例を示すフローチャートである。例えば、サーバ２が、業務アプリケーションを起動するリクエストをクライアント端末３から受信した場合、起動モジュールプロセスが実行される。
【０１２３】
起動モジュールプロセスが実行されると、該起動モジュールプロセスは、業務アプリケーションプロセスをサスペンド状態で起動する（ステップＳ１）。そして、起動モジュールプロセスは、業務アプリケーションプロセスに、排他監視スレッドを埋め込む（ステップＳ２）。
【０１２４】
起動モジュールプロセスは、業務アプリケーションに埋め込んだ排他監視スレッドに起動の指示を出す（ステップＳ３）。該指示に基づいて、排他監視スレッドが起動する。上述したように、排他監視スレッドが起動すると、排他監視スレッドの初期化処理が行なわれる。
【０１２５】
排他監視スレッドは、初期化処理が完了すると、初期化完了通知を起動モジュールプロセスに出力する。起動モジュールプロセスは、初期化完了通知を受けたかを判定する（ステップＳ４）。
【０１２６】
ステップＳ４でＮＯの場合、処理は、次のステップに進まない。ステップＳ４でＹＥＳの場合、排他監視スレッドの初期化処理は完了している。起動モジュールプロセスは、業務アプリケーションプロセスに、メインスレッドを起動する指示を出す（ステップＳ５）。そして、起動モジュールプロセスは、自身のプロセスを終了する処理を行なう（ステップＳ６）。
【０１２７】
図１６は、排他監視スレッドの処理の流れの一例を示すフローチャートである。上述したように、起動モジュールプロセスは、排他監視スレッドに起動の指示を出す。排他監視スレッドは、該起動の指示を受けたかを判定する（ステップＳ１１）。
【０１２８】
ステップＳ１１でＮＯの場合、処理は、次のステップに進まない。ステップＳ１１でＹＥＳの場合、排他監視スレッドは、初期化処理を行なう（ステップＳ１２）。初期化処理が完了すると、排他監視スレッドは、初期化完了通知を起動モジュールプロセスに出力する（ステップＳ１３）。ステップＳ１３の時点では、まだメインスレッドは起動していない。
【０１２９】
そして、排他監視スレッドは、排他監視処理を行なう（ステップＳ１４）。メインスレッドが起動中、各クライアント端末３からのリクエストに応じて、業務アプリケーションプロセスは、複数のスレッド（レスポンダスレッド）を実行する。
【０１３０】
業務アプリケーションプロセスの終了の際、メインスレッドが終了する。排他監視スレッドは、業務アプリケーションプロセスに、他のスレッドがあるかを判定する（ステップＳ１５）。
【０１３１】
ステップＳ１５でＹＥＳの場合、処理は、ステップＳ１４に戻る。ステップＳ１５でＮＯの場合、排他監視スレッドは、自身のスレッドを終了する処理を行なう（ステップＳ１６）。
【０１３２】
図１７は、業務処理の流れの一例を示すフローチャートである。起動モジュールプロセスは、業務アプリケーションプロセスにメインスレッドの起動を指示する起動指示を出す。業務アプリケーションプロセスは、起動指示を受けたかを判定する（ステップＳ２１）。ステップＳ２１でＮＯの場合、処理は、次のステップに進まない。
【０１３３】
ステップＳ２１でＹＥＳの場合、メインスレッドが起動する（ステップＳ２２）。メインスレッドが起動した時点で、排他監視スレッドの初期化処理は完了している。メインスレッドが起動すると、サーバ２は、クライアント端末３からのリクエストの受信を開始する。
【０１３４】
サーバ２が、クライアント端末３からリクエストを受信した場合（ステップＳ２３でＹＥＳ）、メインスレッドは、レスポンダスレッドを起動する（ステップＳ２４）。そして、レスポンダスレッドは、リクエストに応じた処理を行なう（ステップＳ２５）。
【０１３５】
実施形態では、サーバ２は、業務サーバであり、該サーバ２で業務アプリケーションが動作している。従って、クライアント端末３かあらのリクエストは、業務に関するリクエストであり、レスポンダスレッドが実行する処理は、業務に関する処理である。
【０１３６】
ステップＳ２３でＮＯの場合、ステップＳ２４およびＳ２５の処理は行われない。メインスレッドは、自身のメインスレッドが終了するかを判定する（ステップＳ２６）。ステップＳ２６でＮＯの場合、処理は、ステップＳ２３に戻る。ステップＳ２６でＹＥＳの場合、メインスレッドは、自身のメインスレッドを終了する処理を行なう（ステップＳ２７）。
【０１３７】
図１８は、図１６のステップＳ１２における排他監視スレッドの初期化処理の一例を示すフローチャートである。排他監視スレッドは、図１１の例の初期設定テーブルを参照して、各設定値を取得する（ステップＳ３１）。そして、排他監視スレッドは、排他管理テーブルを初期化する（ステップＳ３２）。
【０１３８】
排他監視スレッドは、オリジナルの排他ＡＰＩをラップ化した排他ＡＰＩのラップ関数を登録する（ステップＳ３３）。例えば、排他監視スレッドは、排他監視ＤＬＬに用意されているＯＳの排他ＡＰＩラップ関数を、ＯＳの排他ＡＰＩ名として登録する。
【０１３９】
排他監視スレッドは、スレッド（レスポンダスレッド）に例外を発行し、該スレッドにコールスタック情報を出力させるための例外ハンドラを登録する（ステップＳ３４）。
【０１４０】
図１９および図２０は、排他監視スレッドの処理の流れの一例を示す。排他監視スレッドは、業務アプリケーションプロセス内に、他のスレッドが存在している間、ステップＳ４１〜ステップＳ５５の処理をループする。
【０１４１】
例えば、排他管理テーブルには、複数の排他のそれぞれに対応するレコードが存在する。排他監視スレッドは、排他管理テーブルの各レコードについて、ステップＳ４２〜ステップＳ５４の処理をループする。なお、排他管理テーブルのレコードが１つの場合、ステップＳ４２〜ステップＳ５４の処理のループ回数は、１回である。
【０１４２】
以下、ステップＳ４２〜ステップＳ５４は、１つのレコードについて行なわれる処理である。処理が、ステップＳ４２に戻るごとに、排他管理テーブルの次のレコードについて、ステップＳ４２以降の処理が行なわれる。なお、ステップＳ４２から始まる処理が、ステップＳ５４に到達する前に、ステップＳ４２に戻ることがある。
【０１４３】
排他監視スレッドは、上記レコードのうち、排他処理中の排他情報セットに基づいて、開始日時から現在日時までに経過した時間が、タイムアウト時間に対する設定値Ｖ１％以上であるかの第１判定を行なう（ステップＳ４３）。
【０１４４】
排他監視スレッドは、上記レコードのうち、排他待ちリストの排他情報セットに基づいて、開始日時から現在日時までに経過した時間が、タイムアウト時間に対する設定値Ｖ２％以上のスレッド数を特定する（ステップＳ４４）。
【０１４５】
また、排他監視スレッドは、上記レコードのうち、排他待ちエラー数を取得し、該排他待ちエラー数と、ステップＳ４４で特定されたスレッド数との合計が、設定値Ｖ３を超えているかの第２判定を行う（ステップＳ４５）。
【０１４６】
排他監視スレッドは、第１判定がＹＥＳであるか、または第２判定がＹＥＳであるかを判定する（ステップＳ４６）。例えば、上記開始日時から現在日時までに経過した時間が、タイムアウト時間に対する設定値Ｖ１％以上である場合、第１判定はＹＥＳとなる。また、上記排他待ちエラー数と、ステップＳ４４で特定されたスレッド数との合計が、設定値Ｖ３を超えている場合、第２判定を満たす。
【０１４７】
第１判定でＮＯの場合および第２判定でＮＯの場合、ステップＳ４６はＮＯとなる。この場合、処理は、ステップＳ４２に戻る。ステップＳ４６でＹＥＳの場合、排他に起因するスローダウンが生じた可能性がある。
【０１４８】
ステップＳ４６でＹＥＳの場合、排他監視スレッドは、上記レコードのうち、排他処理中の排他情報セットから、スレッドＩＤを取得し、上記レコードのうち、コールスタック出力数を取得する（ステップＳ４７）。そして、処理は「Ａ」に進む。「Ａ」以降の処理について、図２０を参照して説明する。
【０１４９】
排他監視スレッドは、ステップＳ４７で取得したコールスタック出力数が、設定値Ｖ７未満であるかを判定する（ステップＳ４８）。設定値Ｖ７は、１回の排他処理において、コールスタック情報を取得する数の上限を規定する値である。該上限は、所定の回数の一例である。
【０１５０】
ステップＳ４８でＮＯの場合、コールスタック出力数が上記の上限に達する。この場合、処理は、「Ｂ」からステップＳ４２に戻る。つまり、コールスタック情報の出力が停止される。
【０１５１】
ステップＳ４８でＹＥＳの場合、排他監視スレッドは、現在日時と自身のスレッドＩＤと上記レコードの内容とを調査ログに出力する（ステップＳ４９）。上記現在日時と自身のスレッドＩＤと上記レコードの内容とは、コールスタック情報の出力に対応して、調査ログに出力される。
【０１５２】
排他監視スレッドは、ステップＳ４７で取得したスレッドＩＤのスレッドに対して、コールスタック情報を出力させる例外を送信する（ステップＳ５０）。該例外は、上記スレッドに転送され、該スレッドは、排他監視スレッドの例外ハンドラを呼び出す。
【０１５３】
排他監視スレッドは、例外ハンドラが呼び出されると、例外を受信したスレッドに、スレッドＩＤを含むコールスタック情報を生成させる（ステップＳ５１）。従って、上記スレッドは、コールスタック情報を生成する。生成されたコールスタック情報は、調査ログに出力される（ステップＳ５２）。このため、上記スレッドは、コールスタック情報を調査ログに出力する。これにより、コールスタック情報が取得される。
【０１５４】
排他監視スレッドは、上記レコードのコールスタック出力数をインクリメントする（ステップＳ５３）。そして、処理は、ステップＳ４２に戻る。従って、排他管理テーブルの各レコードについて、ステップＳ４２からステップＳ５４までの処理が行われる。
【０１５５】
なお、ステップ４６でＮＯの場合、またはステップＳ４８でＮＯの場合には、ステップＳ４２からステップＳ５４までの全ての処理が行われることなく、次のレコードについて、上記の処理が行なわれる。
【０１５６】
排他監視スレッドは、業務アプリケーションプロセス内に、他のスレッドが存在する間、ステップＳ４１〜ステップＳ５４の処理を行う。業務アプリケーションプロセス内に、他のスレッドが存在しない場合、排他監視スレッドの処理は終了する。
【０１５７】
次に、スレッド（レスポンダスレッド）が、排他区間の処理の実行を開始する場合の処理の流れについて、説明する。スレッドが、排他区間の処理を実行する際、ラップ化された排他区間開始関数が呼び出される。図２１は、排他区間開始関数の処理の流れの一例を示す。
【０１５８】
スレッドは、自身のスレッドＩＤを取得する（ステップＳ６１）。スレッドは、排他名に基づいて、排他管理テーブルの対応レコードを検索する（ステップＳ６２）。例えば、上記スレッドは、排他区間開始関数の引数で指定された排他名に基づいて、排他管理テーブルの対応レコードを検索する。
【０１５９】
上記スレッドは、対応レコードが存在するかを判定する（ステップＳ６３）。例えば、上記スレッドは、排他管理テーブルに、上記排他名と同じ排他名のレコード（対応レコード）があるか否かに基づいて、ステップＳ６３の判定を行ってもよい。
【０１６０】
ステップＳ６３でＮＯの場合、対応レコードが存在しないため、上記スレッドは、排他管理テーブルに、排他区間開始関数の引数で指定された排他名についての新たなレコードを作成する（ステップＳ６４）。
【０１６１】
ステップＳ６３でＹＥＳの場合、またはステップＳ６４が行われた場合、上記スレッドは、排他情報セットを、対応レコードの排他待ちリストに登録する（ステップＳ６５）。上述したように、排他情報セットは、スレッドＩＤと開始日時とタイムアウト時間との情報を含む。
【０１６２】
上記スレッドは、排他情報セットにおけるタイムアウト時間が無限大に設定されている場合、初期テーブルの設定値Ｖ６を排他待ちリストに登録する。これにより、１つのスレッドが資源を占有し続けることが回避される。上述したように、設定値Ｖ６は、任意の値に設定されてもよい。
【０１６３】
ステップＳ６１からステップＳ６４までの処理は、ラップ化された排他区間開始関数の処理である。ステップＳ６４の処理が実行されると、オリジナルの排他区間開始関数が呼び出される（ステップＳ６６）。
【０１６４】
上述したように、対応テーブルの排他処理中に、他のスレッドの排他情報セットが記録されており、該他のスレッドの排他情報セットにおけるタイムアウト時間が経過している場合、上記スレッドは、排他待ちエラーとなる。
【０１６５】
この場合、オリジナルの排他区間関数を呼び出したとしても、呼び出しは失敗する。一方、上記スレッドが、排他待ちエラーとならない場合、オリジナルの排他区間関数の呼び出しは成功する。
【０１６６】
ステップＳ６７でＹＥＳの場合、上記スレッドは、排他管理テーブルの排他待ちリストの排他情報セットを排他処理中に移動する（ステップＳ６８）。
【０１６７】
ステップＳ６７でＮＯの場合、上記スレッドは、排他管理テーブルの排他待ちリストから、上記スレッドに関する排他情報セットを削除し、排他待ちエラー数をインクリメントする（ステップＳ６９）。
【０１６８】
図２２は、排他区間終了関数の処理の流れの一例を示すフローチャートである。排他処理を実行していたスレッドが、該排他処理の実行を終了する際に、排他区間終了関数が呼び出される。
【０１６９】
上記スレッドは、自身のスレッドＩＤを取得する（ステップＳ７１）。スレッドは、排他名に基づいて、排他管理テーブルの対応レコードを取得する（ステップＳ７２）。例えば、上記スレッドは、排他区間終了関数の引数で指定された排他名に基づいて、排他管理テーブルの対応レコードの内容を取得する。
【０１７０】
上記スレッドは、取得した対応レコードの内容を、記憶部１６の所定領域に記憶する（ステップＳ７３）。そして、上記スレッドは、該スレッドに対応するレコード（対応レコード）の登録情報を削除する（ステップＳ７４）。対応レコードの排他待ちリストに値がない場合、上記スレッドは、対応レコードを排他管理テーブルから削除する。
【０１７１】
ステップＳ７１からステップＳ７４までの処理は、ラップ化された排他区間終了関数が行う。ステップＳ７４の処理が実行されると、オリジナルの排他区間終了関数が呼び出される（ステップＳ７５）。
【０１７２】
上記スレッドは、対応レコードのうち、排他処理中の排他情報セットに基づいて、開始日時から現在日時までに経過した時間が、タイムアウト時間に対する設定値Ｖ１％以上であるかの第３判定を行なう（ステップＳ７６）。
【０１７３】
上記スレッドは、対応レコードの排他待ちリストの排他情報セットのうち、開始日時から現在日時までに経過した時間が、タイムアウト時間に対する設定値Ｖ２％以上のスレッド数を特定する（ステップＳ７７）。
【０１７４】
また、上記スレッドは、上記レコードのうち、排他待ちエラー数を取得し、該排他待ちエラー数と、ステップＳ７７で特定されたスレッド数との合計が、設定値Ｖ３を超えているかの第４判定を行う（ステップＳ４５）。そして、処理は「Ｄ」からステップＳ７９に移る。図２３を参照して、「Ｄ」以降の処理について説明する。
【０１７５】
上記スレッドは、第３判定がＹＥＳであるか、または第４判定がＹＥＳであるかを判定する（ステップＳ７９）。例えば、上記開始日時から現在日時までに経過した時間が、タイムアウト時間に対する設定値Ｖ１％以上である場合、第３判定はＹＥＳとなる。また、上記排他待ちエラー数と、ステップＳ７７で特定されたスレッド数との合計が、設定値Ｖ３を超えている場合、第４判定はＹＥＳとなる。
【０１７６】
第３判定でＮＯの場合および第４判定でＮＯの場合、ステップＳ７９はＮＯとなる。この場合、処理は終了する。ステップＳ７９でＹＥＳの場合、上記スレッドは、排他管理テーブルの排他処理中から排他処理時間を求め、待機する時間（一定時間）を計算する（ステップＳ８０）。
【０１７７】
例えば、上記スレッドは、排他処理時間に対する所定の割合（設定値Ｖ５）の時間と排他解放後の最大待ち時間（設定値Ｖ６）とのうち、短い方の時間を上記一定時間として計算してもよい。
【０１７８】
上記スレッドは、上記一定時間が経過したかを判定する（ステップＳ８１）。ステップＳ８１でＮＯの場合、処理は、次のステップに進まない。ステップＳ８１でＹＥＳの場合、上記スレッドの実行が再開すると共に、ステップＳ７３で記憶部１６に記憶した対応レコードを調査ログに出力される（ステップＳ８２）。
【０１７９】
上記スレッドは、一定間隔で、スレッドＩＤを含むハードウェア利用率を取得し、該ハードウェア利用率を調査ログに出力する（ステップＳ８３）。上述したように、記憶制御部１４は、スレッドＩＤを含むコールスタック情報を調査ログに出力する。また、記憶制御部１４は、スレッドＩＤを含むハードウェア利用率を調査ログに出力する。
【０１８０】
従って、記憶制御部１４は、コールスタック情報と対応付けられたハードウェア利用率の情報を含む調査ログを記憶部１６に記憶する。
【０１８１】
なお、上記スレッドは、上記一定時間が経過した後、所定の開始時間から所定の終了時間までの間、任意のタイミングで複数のハードウェア利用率を取得してもよい。
【０１８２】
＜サーバのハードウェア構成の一例＞
次に、図２４の例を参照して、サーバ２のハードウェア構成の一例を説明する。図２４の例に示すように、バス１００に対して、プロセッサ１１１とRandom Access Memory(RAM)１１２とRead Only Memory(ROM)１１３とが接続される。また、該バス１００に対して、補助記憶装置１１４と媒体接続部１１５と通信インタフェース１１６とが接続される。
【０１８３】
プロセッサ１１１はＲＡＭ１１２に展開されたプログラムを実行する。実行されるプログラムとしては、実施形態における処理を行うプログラムが適用されてもよい。
【０１８４】
ＲＯＭ１１３はＲＡＭ１１２に展開されるプログラムを記憶する不揮発性の記憶装置である。補助記憶装置１１４は、種々の情報を記憶する記憶装置であり、例えばハードディスクドライブや半導体メモリ等が適用されてもよい。媒体接続部１１５は、可搬型記録媒体１１５Ｍと接続可能に設けられている。
【０１８５】
可搬型記録媒体１１５Ｍとしては、可搬型のメモリ（例えば、半導体メモリ）や光学式ディスク（例えば、Compact Disc(CD)やDigital Versatile Disc(DVD)）等が適用されてもよい。この可搬型記録媒体１１５Ｍに実施形態の処理を行うプログラムが記録されていてもよい。
【０１８６】
上述した処理部１１と起動制御部１２と排他制御部１３とは、与えられたプログラムをプロセッサ１１１が実行することにより実現されてもよい。また、通信部１５は、通信インタフェース１１６により実現されてもよい。記憶部１６は、ＲＡＭ１１２や補助記憶装置１１４等により実現されてもよい。
【０１８７】
ＲＡＭ１１２、ＲＯＭ１１３、補助記憶装置１１４および可搬型記録媒体１１５Ｍは、何れもコンピュータ読み取り可能な有形の記憶媒体の一例である。これらの有形な記憶媒体は、信号搬送波のような一時的な媒体ではない。
【０１８８】
＜その他＞
本実施形態は、以上に述べた実施の形態に限定されるものではなく、本実施形態の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。
【符号の説明】
【０１８９】
１    システム
２    サーバ
３    クライアント端末
１１    処理部
１２    起動制御部
１３    排他制御部
１４    記憶制御部
１５    通信部
１６    記憶部
１１１    プロセッサ
１１２    ＲＡＭ
１１３    ＲＯＭ
【図１】
2018181131.tif 000003
【図２】
2018181131.tif 000004
【図３】
2018181131.tif 000005
【図４】
2018181131.tif 000006
【図５】
2018181131.tif 000007
【図６】
2018181131.tif 000008
【図７】
2018181131.tif 000009
【図８】
2018181131.tif 000010
【図９】
2018181131.tif 000011
【図１０】
2018181131.tif 000012
【図１１】
2018181131.tif 000013
【図１２】
2018181131.tif 000014
【図１３】
2018181131.tif 000015
【図１４】
2018181131.tif 000016
【図１５】
2018181131.tif 000017
【図１６】
2018181131.tif 000018
【図１７】
2018181131.tif 000019
【図１８】
2018181131.tif 000020
【図１９】
2018181131.tif 000021
【図２０】
2018181131.tif 000022
【図２１】
2018181131.tif 000023
【図２２】
2018181131.tif 000024
【図２３】
2018181131.tif 000025
【図２４】
2018181131.tif 000026