JP2007199811A - プログラム制御方法、計算機およびプログラム制御プログラム - Google Patents

Abstract

【課題】計算機において、業務処理で複数のプロセスにまたがる複数のプログラムを並列実行する場合に、業務処理の同時実行数を制御する。
【解決手段】計算機１００の主記憶装置２０は、業務ごとに実行中の業務処理に固有のリクエスト識別子を管理する業務実行状態管理テーブル３１１と、リクエスト識別子ごとに、業務処理を実行中の実行単位を管理するリクエストトレース３３１と、実行単位ごとにリソース使用量を管理するリソース使用状況テーブル５１０とを備える。ＣＰＵ１０は、５１０に設定された実行単位ごとのリソース使用量を、３３１を参照してリクエスト識別子ごとに集計する。集計した値を、３１１を参照して業務ごとに合計する。合計した値が最大である業務を、停止すべき業務とする。３１１に管理される停止すべき業務のリクエスト識別子から、所定の選択条件によって、停止すべきものを選択し、そのリクエスト識別子の業務処理を停止する。
【選択図】図１

Description

本発明は、計算機において、プログラムを並行実行する場合のプログラム制御技術に関する。

オンラインシステムを構成する計算機は、その計算機にインストールされたプログラムに対する、その計算機の入力端末またはオンライン接続された他の計算機から送られた要求（リクエスト）を処理する。計算機が複数の要求を処理する場合に、性能向上などのためにアプリケーションプログラムを所定の処理単位（例えば、プロセス）に割り当てることによって、同時に実行することがある。そして、その処理を効率よく進めるために、その同時実行数をプロセス単位に制御する技術がある（例えば特許文献１参照）。これによると、１つの要求に対応する業務処理が１つのプロセスで実行される場合には、同時実行数を業務単位に制御できることになる。
特開平９−３０５４１４号公報

しかしながら、業務処理では、１つのプロセス上で１つのアプリケーションプログラムが実行されるとは限らず、１つのアプリケーションプログラムが動作するプロセスが複数存在し、それぞれのプロセス上でアプリケーションプログラムが実行される場合には、業務処理におけるプログラムの同時実行数を制御することができないという問題がある。

そこで、本発明は、前記問題に鑑み、計算機において、業務処理で複数のプロセスにまたがる複数のプログラムを並列実行する場合に、業務処理の同時実行数を制御する手段を提供することを課題とする。ここでいうアプリケーションプログラムは、あるプロセスにおいて起動（実行）されるプログラムをいう。

前記課題を解決する本発明は、送られた要求に対して業務処理を行う計算機が、その業務処理を複数のプロセスにまたがる複数のプログラムによって実行する場合に、業務処理の実行数を制御するプログラム制御方法であって、計算機の記憶部が、業務処理ごとのリソース使用量を管理し、計算機の処理部が、リソース使用量が所定の閾値を超えたときに、リソース使用量が最大である業務処理を停止することを主な特徴とする。なお、本発明は、他のプログラム制御方法、計算機およびプログラム制御プログラムを含む。

本発明によれば、計算機において、業務処理で複数のプロセスにまたがる複数のプログラムを並列実行する場合に、業務処理の同時実行数を制御することができる。

以下、本発明を実施するための最良の形態について図面を参照して詳細に説明する。

≪計算機の構成と概要≫
図１は、本発明の実施の形態に係る計算機の構成を示す図である。計算機１００は、ＣＰＵ（Central Processing Unit、処理部）１０および主記憶装置（記憶部）２０を含んで構成される。ＣＰＵ１０は、主記憶装置２０にロードされたプログラムを実行する中央処理装置である。主記憶装置２０は、ＣＰＵ１０によって実行されるプログラムや参照、更新されるデータを記憶するメモリである。

主記憶装置２０には、業務管理部３０、業務停止部４０およびリソース監視部５０がロードされるとともに、プログラム（以下、アプリケーションという）に対するリクエスト（要求）を受けて業務処理を実行するプロセスが生成される。

業務管理部３０は、業務処理の実行を管理する機能を有し、業務実行状態記録部３１０、業務実行優先度定義部３２０、リクエストトレース記録部３３０およびアプリケーショントレース記録部３４０を含んで構成される。業務実行状態記録部３１０は、業務ごとのアプリケーションの構成やその実行状態を管理する業務実行状態管理テーブル３１１を記録する。その詳細は後述する（図２参照）。業務実行優先度定義部３２０は、業務処理を実行する優先度を定義する業務実行優先度定義テーブル３２１を有する。その詳細は後述する（図３参照）。リクエストトレース記録部３３０は、リクエストに対する業務処理に係るアプリケーションのメソッドをスタックするリクエストトレース（処理トレース）３３１を記録する。その詳細は後述する（図４参照）。アプリケーショントレース記録部３４０は、リクエストに対する処理の開始時刻や終了時刻などのアプリケーショントレース３４１を記録する。その詳細は後述する（図５参照）。

業務停止部４０は、業務処理の実行を停止する機能を有し、同時実行数調整比率定義テーブル４１０およびリクエスト停止方法定義テーブル４２０を含んで構成される。同時実行数調整比率定義テーブル４１０は、業務処理を停止する場合の、同時実行数を調整するための比率を定義する。その詳細は後述する（図６参照）。リクエスト停止方法定義テーブル４２０は、業務処理を停止する場合の、その停止方法を定義する。その詳細は後述する（図７参照）。

リソース監視部５０は、業務処理の実行においてメモリなどのリソースの状況を監視する機能を有し、リソース使用状況テーブル５１０およびリソース閾値定義テーブル５２０を含んで構成される。リソース使用状況テーブル５１０は、ＣＰＵやメモリの使用状況（リソース使用量）を示す。その詳細は後述する（図８参照）。リソース閾値定義テーブル５２０は、業務処理を停止する場合に判断基準となる閾値を定義する。その詳細は後述する（図９参照）。

プロセスは予め生成され、外部（入力端末または他の計算機）からアプリケーションに対するリクエストを受信した場合に、そのリクエストに対応した処理がプロセス上で実行される。プロセス上では、スレッドを起動して処理を実行する。プロセス上で、複数のリクエストに対応した複数の処理が同時に実行されることになるが、その同時に実行されるリクエストの数が、同時実行数である。換言すれば、複数のリクエストに対応した複数の業務処理の数が、同時実行数である。
実行単位とは、業務内の各アプリケーションのメソッドを実行するプロセス上の単一のスレッドを表す。複数のリクエストを受けて同一アプリケーションの同一のメソッドを実行する場合、そのリクエストごとに実行単位（スレッド）は異なると言える。

なお、１つのリクエストに対して、１つのアプリケーションの処理が実行されるとは限らない。図１に示すように、所定のリクエストに対して、アプリケーション１が実行され、そのアプリケーション１からアプリケーション２がコール（呼び出し）されたり、アプリケーション３がコールされたりする。また、アプリケーション１からコールされたアプリケーション２によって、さらにアプリケーション３がコールされることもある。なお、ここでは、プロセスＡがアプリケーション１の処理を実行し、プロセスＢがアプリケーション２の処理を実行し、プロセスＣがアプリケーション３の処理を実行するものとする。すなわち、１つのリクエストに対する業務処理が、複数のプロセスにまたがる複数のアプリケーションで行われるのである。この場合に、アプリケーション間のコールは、プロセス間通信によって行われる。

計算機１００の動作概要としては、業務処理を実行している間に、リソース使用量が閾値を超えた場合に、リソース監視部５０がその旨を業務停止部４０に通知する。次に、業務停止部４０が、その通知を受けて、業務管理部３０やリソース監視部５０のテーブルやトレースを参照し、所定の手順に従って停止すべき業務およびその処理を決定する。そして、その決定した処理に係るスレッド（実行単位）を順に停止する。

≪テーブルの構成≫
図２は、業務実行状態管理テーブルの構成を示す図である。業務実行状態管理テーブル３１１は、業務ごとにアプリケーションの構成やその実行状態を管理するテーブルであり、業務ＩＤ、アプリケーションの構成および実行中の業務のリクエスト識別子を項目として含むレコードから構成される。業務ＩＤは、リクエストに対応した業務に固有の番号である。アプリケーションの構成は、業務ＩＤに対応した業務処理を行うのに具体的に実行されるプロセス、アプリケーションおよびそのメソッドを示すものであり、業務ＩＤごとに事前に登録される。業務ＩＤごとのアプリケーションの構成は、１つの場合もあるし、複数の場合もある。そのメソッドを実行する単位がスレッドである。

実行中の業務のリクエスト識別子は、リクエストに対応した業務処理を最初に実行するスレッドを示す識別子であり、具体的にはプロセスに固有のプロセスＩＤおよびスレッドに固有のスレッドＩＤからなる。これは、業務処理に固有なデータ（処理ＩＤ）である。図２を参照すると、例えば、（ｐ（process）ｉｄ１，ｔ（thread）ｉｄ１）などのように示している。実行中の業務のリクエスト識別子は、古いものから順番に格納されているものとする。なお、業務１および業務２については、複数の処理が実行中であるが、業務３については、実行中のスレッドがないので処理が実行されていないことが分かる。

図３は、業務実行優先度定義テーブルの構成を示す図である。業務実行優先度定義テーブル３２１は、リクエストに対応した業務処理を実行する場合に、複数の業務処理に関する優先度を定義するテーブルであり、業務ＩＤおよびレベルを項目として含むレコードから構成される。業務ＩＤは、リクエストに対応した業務に固有の番号である。レベルは、業務処理の優先度を示すものであり、ここでは、業務１、業務２および業務３に対して、それぞれ高、低および中の優先度が付けられている。従って、優先順位は、業務１、業務３、業務２の順となる。業務実行優先度定義テーブル３２１は、停止する業務処理を決定する場合に、優先度が低い業務処理を選択するための判断基準となるものであり、事前に登録される。

図４は、リクエストトレースの構成を示す図である。リクエストトレース３３１は、リクエストに対する業務処理に係るアプリケーションのメソッドをスタックするものであり、リクエスト識別子およびスタックを項目として含むレコードから構成される。リクエスト識別子は、リクエストに対応した業務処理を実行している最初のスレッドを示す識別子であり、プロセスＩＤおよびスレッドＩＤからなる。これによると、リクエスト識別子は、リクエストに対応した業務処理に固有なデータ（処理ＩＤ）となる。スタックは、リクエスト識別子に対応した業務処理を実行している、アプリケーションのメソッドのネスト（コール関係の深さ）を示す。図４に示すように、例えば、リクエスト識別子ｐｉｄ１，ｔｉｄ１のスタックは、下からアプリケーション１メソッドａ、アプリケーション２メソッドｂ、アプリケーション３メソッドｃの順にスタックされている。これは、図２に示す業務１のアプリケーションの構成に対応したものになっている。また、図４には示されていないが、アプリケーションのメソッドに対応して、その処理を実行するプロセスのプロセスＩＤおよびスレッドのスレッドＩＤが記録されているものとする。

図５は、アプリケーショントレースの構成を示す図である。アプリケーショントレース３４１は、リクエスト識別子および開始時刻，終了時刻を含むレコードから構成される。リクエスト識別子は、リクエストに対応した業務処理を実行している最初のスレッドを示す識別子であり、プロセスＩＤおよびスレッドＩＤからなる。開始時刻，終了時刻は、スレッドの処理が開始した時刻および終了した時刻である。従って、アプリケーショントレース３４１の開始時刻があって、終了時刻がない場合には、リクエスト識別子に対応する業務処理のスレッドが実行中であることを示す。また、（アプリケーション１，アプリケーション２）は、当該スレッドが、アプリケーション１からコールされたアプリケーション２の実行単位であることを示す。

図６は、同時実行数調整比率定義テーブルの構成を示す図である。同時実行数調整比率定義テーブル４１０は、業務処理を停止する場合に、同時に実行されるリクエストの数を調整するための比率を定義するテーブルであり、業務の同時実行数削減割合を項目として含むレコードから構成される。業務の同時実行数削減割合は、停止する業務処理が決まった場合に、どのくらいのリクエストを停止するのかを示す。図６では、例えば、業務の同時実行数削減割合が５０％になっており、同時に実行されているリクエストの数の５０％を削減することが示されている。同時実行数調整比率定義テーブル４１０は、事前に登録される。

図７は、リクエスト停止方法定義テーブルの構成を示す図である。リクエスト停止方法定義テーブル４２０は、停止するリクエストの選択方法を項目として含むレコードから構成される。停止するリクエストの選択方法は、停止する業務処理を選択する基準を示すものであり、図７に示す「１：経過時間優先」のほか、「２：受付順優先」や「３：スタックの深さ優先」などがある。

経過時間優先は、処理開始後、経過時間が長い業務処理を選択するものである。これは、経過時間が長い処理は、障害によってハングアップしている可能性があるので、優先して停止させるという考え方による。次に、受付順優先は、リクエストの受付順が新しい業務処理を選択するものである。これは、受付順が新しい処理は、処理を開始してから間もないため、停止による手戻りなどの影響が少ないので、優先して停止させるという考え方による。そして、スタックの深さ優先は、スタックの深い業務処理を選択するものである。これは、スタックの深い処理は、その分メモリなどのリソースを消費している可能性があるので、優先して停止させるという考え方による。リクエスト停止方法定義テーブル４２０については、停止するリクエストの選択方法がユーザによって選択可能であり、その選択結果が事前に登録される。これによれば、ユーザは、業務処理の特性などを考慮して、適切な「停止するリクエストの選択方法」を決めることができる。

図８は、リソース使用状況テーブルの構成を示す図である。リソース使用状況テーブル５１０は、スレッドごとにＣＰＵやメモリの使用状況を示すテーブルであり、プロセスＩＤ、スレッドＩＤ、ＣＰＵ利用率およびメモリ使用量を項目として含むレコードから構成される。プロセスＩＤは、プロセスに固有の番号である。スレッドＩＤは、プロセス内でスレッドに固有の番号である。ＣＰＵ利用率（単位：％）は、そのスレッドが処理をする場合のＣＰＵの利用率を示す。メモリ使用量（単位：ＭＢｙｔｅ）は、そのスレッドが処理をする場合のメモリの使用量を示す。

図９は、リソース閾値定義テーブルの構成を示す図である。リソース閾値定義テーブル５２０は、プロセスＩＤおよび閾値情報を項目として含むレコードから構成される。プロセスＩＤは、プロセスに固有の番号である。閾値情報は、業務処理を停止するか否かの判断基準を示すものであり、ＣＰＵ利用率やメモリ使用量が閾値として設定される。図９によると、例えば、プロセスＩＤｐｉｄ１の業務処理は、ＣＰＵ利用率が４０％を超えた場合、または、メモリ使用量が１０２４ＭＢを超えた場合に停止するべきであることが分かる。なお、ＣＰＵ利用率やメモリ使用量が閾値を超えた場合に停止してもよいし、閾値を含んでそれ以上になった場合に停止してもよい。リソース閾値定義テーブル５２０は、事前に登録される。

≪計算機の処理≫
次に、前記のような機能構成およびテーブルを有する計算機１００が、同時実行のリクエスト数を業務単位に制御する処理について説明する。まず、計算機１００の初期化処理を説明する。次に、計算機１００が外部からリクエストを受信した場合の処理を説明し、その中で業務処理の停止を行う手順を概説する。そして、その手順である、停止対象の業務を決定する処理、停止対象のリクエストを決定する処理およびリクエストの停止処理をそれぞれ詳細に説明する。さらに、トレース記録およびリクエスト停止の処理の具体例を説明する。

図１０は、初期化処理を示すフローチャートである。この初期化処理は、計算機１００が各テーブルの設定値を事前に登録する処理であり、計算機１００の電源投入時にデフォルト値として、または、ユーザの選択によって設定する処理である。まず、業務管理部３０は、業務実行状態管理テーブル３１１に業務実行状態を登録する（Ｓ１００１）。ここで、業務実行状態とは、業務ＩＤに対応する業務処理におけるアプリケーションの構成である（図２参照）。次に、業務管理部３０は、業務実行優先度定義テーブル３２１に業務実行優先度を登録する（Ｓ１００２）。ここで、業務実行優先度とは、業務ＩＤに対応する業務処理のレベルである（図３参照）。そして、業務停止部４０は、同時実行数調整比率定義テーブル４１０に同時実行数調整比率を登録する（Ｓ１００３）。ここで、同時実行数調整比率とは、業務の同時実行数削減割合である（図６参照）。続いて、業務停止部４０は、リクエスト停止方法定義テーブル４２０にリクエスト停止方法を登録する（Ｓ１００４）。ここで、リクエスト停止方法とは、停止するリクエストの選択方法である（図７参照）。さらに、リソース監視部５０は、リソース閾値定義テーブル５２０にリソース閾値を登録する（Ｓ１００５）。ここで、リソース閾値とは、プロセスＩＤに対応したプロセスのＣＰＵ利用率およびメモリ使用量である（図９参照）。

図１１は、リクエスト受信処理を示すフローチャートである。この処理は、計算機１００がその入力端末または他の計算機からリクエストを受信した場合の処理である。まず、計算機１００は、アプリケーションに対するリクエストを受信する（Ｓ１１０１）。そして、これをトリガにして、リソース監視部５０が既に実行中の業務処理についてリソースの閾値を超えた否かを判断する（Ｓ１１０２）。具体的には、リソース使用状況テーブル５１０を参照して、同じプロセスＩＤごとに、スレッドのＣＰＵ利用率およびメモリ使用量をそれぞれ合計し、その合計値がリソース閾値定義テーブル５２０の閾値情報を超えたか否かをチェックする。

リソースの閾値を超えた場合には（Ｓ１１０２のＹｅｓ）、計算機１００は、受信したリクエストの処理は行わないので、その要求元にエラーメッセージを送信する（Ｓ１１０３）。そして、リソース監視部５０は、業務停止部４０にリソース閾値の超過を通知する（Ｓ１１０４）。これに対して、業務停止部４０は、まず、停止する対象となる業務処理を決定する（Ｓ１１０５）。次に、停止する対象となるリクエストを決定する（Ｓ１１０６）。そして、実際にリクエストを停止した（Ｓ１１０７）後、リクエスト受信処理を終了する。なお、Ｓ１１０５、Ｓ１１０６およびＳ１１０７の処理の詳細は後述する（図１３、図１４および図１５参照）。

リソースの閾値を超えていない場合（Ｓ１１０２のＮｏ）、計算機１００は、受信したリクエストを受け付けて（Ｓ１１０８）、そのリクエストに対応した業務処理（リクエスト処理）を行う（Ｓ１１０９）。その詳細は後述する（図１２参照）。その業務処理を行った後、リクエスト受信処理を終了する。

ここで、リソースの閾値を超えた場合に（Ｓ１１０２のＹｅｓ）、エラーメッセージを送信することなく、受信したリクエストをキューに配置して、その処理を一旦待たせるようにしてもよい。このとき、リクエストを停止した（Ｓ１１０７）後、リクエスト受信処理を終了することなく、再度リソースの閾値を超えた否かを判断する（Ｓ１１０２）。これによれば、リソースの閾値チェックおよびリクエスト停止を行って、リソースの閾値を超えない状態になった場合に、キューに配置したリクエストに対応した業務処理を行うことができる。なお、リソースの閾値チェックおよびリクエスト停止を行っている間に、所定の時間が経過したときには、処理のタイムアウトを意味するエラーメッセージを要求元に送信するようにしてもよい。

図１２は、リクエスト処理の詳細な動作を示すシーケンス図である。このシーケンス図では、業務処理の詳細ではなく、アプリケーション間にまたがる処理の制御上必要な動作を中心に説明する。まず、アプリケーション１は、リクエスト１を受信すると、リクエスト識別子を割り当てる（Ｓ１２０１）。具体的には、アプリケーション１のプロセスが、リクエスト１を受け付けて、その業務処理をスレッドで実行するが、そのときのプロセスに固有のプロセスＩＤおよび最初に実行するスレッドに固有のスレッドＩＤをリクエスト識別子とする。次に、入口トレースを記録する（Ｓ１２０２）。具体的には、業務実行状態管理テーブル３１１（図２参照）にリクエスト識別子を登録する。さらに、リクエストトレース３３１のリクエスト識別子に対応するスタック（図４参照）に、自らのアプリケーション名およびメソッド名を記録するとともに、アプリケーショントレース３４１のリクエスト識別子に対応する開始時刻に現在の時刻を記録する（以下同様）。そして、アプリケーション１は、アプリケーション２をコールする。

アプリケーション２は、コールされた直後に入口トレースを記録する（Ｓ１２０３）。そして、アプリケーション３をコールする。アプリケーション３は、コールされた直後に入口トレースを記録する（Ｓ１２０４）。次に、コール元にリターンする直前に、出口トレースを記録する（Ｓ１２０５）。具体的には、リクエストトレース３３１のリクエスト識別子に対応するスタック（図４参照）から、自身のアプリケーション名およびメソッド名を削除するとともに、アプリケーショントレース３４１のリクエスト識別子に対応する終了時刻に現在の時刻を記録する（以下同様）。そして、アプリケーション２にリターンする。

アプリケーション２は、コール元にリターンする直前に、出口トレースを記録する（Ｓ１２０６）。そして、アプリケーション１にリターンする。アプリケーション１は、処理を終了する直前に、出口トレースを記録する（Ｓ１２０７）。なお、出口トレースを記録する場合には、業務実行状態管理テーブル３１１（図２参照）のリクエスト識別子を削除する。そして、要求元に何らかの応答を送信して、処理を終了する。

一方、アプリケーション１は、リクエスト２を受信した場合には、リクエスト識別子を割り当てて（Ｓ１２０８）、業務実行状態管理テーブル３１１（図２参照）にリクエスト識別子を登録し、入口トレースを記録する（Ｓ１２０９）。そして、アプリケーション３をコールする。アプリケーション３は、コールされた直後に入口トレースを記録する（Ｓ１２１０）。その後、コール元にリターンする直前に、出口トレースを記録する（Ｓ１２１１）。そして、アプリケーション１にリターンする。アプリケーション１は、処理を終了する直前に、出口トレースを記録する（Ｓ１２１２）。この場合、業務実行状態管理テーブル３１１（図２参照）のリクエスト識別子を削除する。そして、要求元に何らかの応答を送信して、処理を終了する。

図１３は、停止対象の業務を決定する処理を示すフローチャートである。計算機１００の業務停止部４０は、業務管理部３０の業務実行状態管理テーブル３１１から業務実行状態を取得する（Ｓ１３０１）。また、リソース監視部５０のリソース使用状況テーブル５１０からリソース使用状況を取得する（Ｓ１３０２）。そして、取得した業務実行状態およびリソース使用状況からリソース使用量が最大である業務を抽出する（Ｓ１３０３）。具体的には、まず、業務実行状態管理テーブル３１１から業務ＩＤごとに実行中の業務のリクエスト識別子を取得する。次に、リクエストトレース３３１を参照して、リクエスト識別子の業務処理を実行中のプロセスＩＤとスレッドＩＤ（スタックに含まれる）を取得する。続いて、リソース使用状況テーブル５１０を参照して、その実行中のプロセスＩＤとスレッドＩＤのＣＰＵ利用率およびメモリ使用量を、それぞれリクエスト識別子ごとに集計し、さらに、その集計した値を業務ＩＤごとに合計する。そして、ＣＰＵ利用率の合計値またはメモリ使用量の合計値が最大である業務ＩＤを抽出する。

業務停止部４０は、抽出された業務が複数あるか否かを判断する（Ｓ１３０４）。これは、ＣＰＵ利用率の合計値またはメモリ使用量の合計値が最大である業務ＩＤが複数あるか否かによって判断する。複数ある場合には（Ｓ１３０４のＹｅｓ）、業務実行優先度定義テーブル３２１から複数ある業務ＩＤのレベル（業務実行優先度）を取得する（Ｓ１３０５）。そして、取得したレベルのうち、レベル（業務実行優先度）が最も低いものを抽出する（Ｓ１３０６）。それが、停止対象の業務となる。なお、レベルが最も低いものが複数抽出された場合には、そのすべてが停止対象の業務となる。Ｓ１３０４で抽出された業務が１つである場合には（Ｓ１３０４のＮｏ）、その１つの業務が停止対象となる。

図１４は、停止対象のリクエストを決定する処理を示すフローチャートである。計算機１００の業務停止部４０は、まず、業務管理部３０の業務実行状態管理テーブル３１１からリクエスト実行状態を取得する（Ｓ１４０１）。具体的には、業務実行状態管理テーブル３１１から、停止対象の業務ＩＤについて実行中の業務のリクエスト識別子の数を把握する。これは、当該業務の現在実行中のリクエスト数を把握することを意味する。次に、同時実行数調整比率定義テーブル４１０から業務の同時実行数削減割合（同時実行数調整比率）を取得する（Ｓ１４０２）。そして、取得した実行中のリクエスト数および業務の同時実行数削減割合を積算することによって、停止すべきリクエスト数を決定する（Ｓ１４０３）。

続いて、業務停止部４０は、リクエスト停止方法定義テーブル４２０から停止するリクエストの選択方法（リクエスト停止方法）を取得する（Ｓ１４０４）。停止方法のタイプが１（経過時間優先）である場合（Ｓ１４０５の１）、業務管理部３０からアプリケーショントレース３４１を取得する（Ｓ１４０６）。そして、開始時刻が設定されていて、終了時刻が設定されていないもののうち、開始時刻からの現在時刻までの経過時間が長いリクエスト識別子を停止リクエスト数分抽出する（Ｓ１４０７）。

停止方法のタイプが２（受付順優先）である場合（Ｓ１４０５の２）、業務停止部４０は、業務管理部３０の業務実行状態管理テーブル３１１（業務実行状態）を取得する（Ｓ１４０８）。そして、実行中の業務のリクエスト識別子を下から順に、すなわち、受付順が新しいリクエストを停止リクエスト数分抽出する（Ｓ１４０９）。

停止方法のタイプが３（スタックの深さ優先）である場合（Ｓ１４０５の３）、業務停止部４０は、業務管理部３０のリクエストトレース３３１を取得する（Ｓ１４１０）。そして、スタックされているアプリケーションのメソッドの数が多い、すなわち、スタックの深いリクエストを停止リクエスト数分抽出する（Ｓ１４１１）。なお、停止すべきリクエストを抽出したら、処理を終了する。

図１５は、アプリケーションの停止処理を示すフローチャートである。計算機１００の業務停止部４０は、まず、業務管理部３０からリクエストトレース３３１を取得する（Ｓ１５０１）。次に、そのリクエストトレース３３１からスタックを抽出する（Ｓ１５０２）。そして、そのスタックの情報に基づいて、図１４のフローチャートで示した停止対象のリクエスト決定処理で抽出したリクエストを受け付けるアプリケーションの入口を閉塞する（Ｓ１５０３）。具体的には、サーバプログラムに対して、当該リクエストを受信した場合に、そのリクエストを受け付けることなく、その要求元にエラーメッセージを送信するように指示する。続いて、現在実行中のスレッドから順にスレッドを停止する（Ｓ１５０４）。具体的には、スタックの上から順にアプリケーションのメソッドの実行を中止する。さらに、停止したリクエストに該当するリクエストトレース３３１を削除する（Ｓ１５０５）。これは、蓄積されたトレース情報ではなく、実行を停止されたリクエスト自体のトレース（瞬間値）を削除するものである。従って、停止されたリクエストは処理されなかったものとみなされる。また、業務実行状態管理テーブル３１１における実行中の業務のリクエスト識別子を削除する（Ｓ１５０６）。これは、停止されたリクエストは実行中でなくなるので、それに対応するリクエスト識別子を削除するものである。

≪トレース記録の具体例≫
次に、複数のプロセスにまたがった複数のアプリケーションの実行によって業務処理が行われる場合の、トレース記録の具体例について説明する。図１６および図１７は、図１２のリクエスト１の業務処理におけるトレース記録の各ステップをタイミングとした遷移を示す図である。ここでは、遷移するトレースとして、業務実行状態管理テーブル３１１の「実行中の業務のリクエスト識別子」（図２参照）、リクエストトレース３３１の「スタック」（図４参照）および「アプリケーショントレース」３４１（図５参照）を示している。

図１６を参照すると、まず、計算機１００が外部からリクエストを受け付ける前の初期化時は、業務実行状態管理テーブル３１１にアプリケーションの構成を記録しておく。このとき、実行中の業務のリクエストはないので、リクエスト識別子は空となる。

次に、リクエストを受け付けたサーバプログラムがアプリケーション１のメソッドａを呼び出すと、入口トレースが記録される（Ｓ１２０２）。このとき、リクエスト識別子が割り当てられ、業務実行状態管理テーブル３１１に実行中の業務のリクエスト識別子（ｐｉｄ１，ｔｉｄ１）が登録される。リクエストトレース３３１では、リクエスト識別子（ｐｉｄ１，ｔｉｄ１）をキーにして、アプリケーション１のメソッドａがスタックに積まれる。アプリケーショントレース３４１には、呼び出し先がアプリケーション１の配列にリクエスト識別子（ｐｉｄ１，ｔｉｄ１）と開始時刻ｔ１が登録される。

そして、アプリケーション１のメソッドaからアプリケーション２のメソッドｂを呼び出すと、入口トレースが記録される（Ｓ１２０３）。このとき、リクエストトレース３３１では、リクエスト識別子（ｐｉｄ１，ｔｉｄ１）に対して、アプリケーション２のメソッドｂがスタックに積まれる。アプリケーショントレース３４１には、呼び出し元がアプリケーション１、呼び出し先がアプリケーション２の配列にリクエスト識別子（ｐｉｄ１，ｔｉｄ１）と開始時刻ｔ２が登録される。

続いて、アプリケーション２のメソッドｂからアプリケーション３のメソッドｃを呼び出すと、入口トレースが記録される（Ｓ１２０４）。このとき、リクエストトレース３３１では、リクエスト識別子（ｐｉｄ１，ｔｉｄ１）に対して、アプリケーション３のメソッドｃがスタックに積まれる。アプリケーショントレース３４１には、呼び出し元がアプリケーション２、呼び出し先がアプリケーション３の配列にリクエスト識別子（ｐｉｄ１，ｔｉｄ１）と開始時刻ｔ３が登録される。

続いて図１７を参照して、アプリケーション３のメソッドｃの処理が終了する直前では、出口トレースが記録される（Ｓ１２０５）。このとき、リクエストトレース３３１のリクエスト識別子（ｐｉｄ１，ｔｉｄ１）に対して、アプリケーション３のメソッドｃのスタックが削除される。アプリケーショントレース３４１には、呼び出し元がアプリケーション２、呼び出し先がアプリケーション３の配列のリクエスト識別子（ｐｉｄ１，ｔｉｄ１）に対して、終了時刻ｔ４が記録される。

次に、アプリケーション２のメソッドｂの処理が終了する直前では、出口トレースが記録される（Ｓ１２０６）。このとき、リクエストトレース３３１のリクエスト識別子（ｐｉｄ１，ｔｉｄ１）に対して、アプリケーション２のメソッドｂのスタックが削除される。アプリケーショントレース３４１には、呼び出し元がアプリケーション１、呼び出し先がアプリケーション２の配列のリクエスト識別子に対して、終了時刻ｔ５が記録される。

そして、アプリケーション１のメソッドａの処理が終了する直前では、出口トレースが記録される（Ｓ１２０７）。このとき、リクエストトレース３３１のリクエスト識別子（ｐｉｄ１，ｔｉｄ１）に対して、アプリケーション１のメソッドａのスタックが削除される。アプリケーショントレース３４１には、呼び出し先がアプリケーション１の配列のリクエスト識別子（ｐｉｄ１，ｔｉｄ１）に対して、終了時刻ｔ６が記録される。リクエストトレース３３１のスタックが空になったことに伴って、業務実行状態管理テーブル３１１の実行中の業務のリクエスト識別子（ｐｉｄ１，ｔｉｄ１）が削除される。

≪リクエスト停止の具体例≫
続いて、リクエストを停止する処理の具体例について説明する。図１８は、所定の時刻における業務処理の状態を示す図である。ここで、リクエスト１およびリクエスト３に対する業務ＩＤは業務１であり、リクエスト２に対する業務ＩＤは業務２であるとする。図１９ないし図２５は、図１８の時刻における他の定義やトレースの設定内容を示している。図１９の業務実行状態管理テーブル３１１には、業務１のリクエスト識別子（ｐｉｄ１，ｔｉｄ１）と（ｐｉｄ１，ｔｉｄ３）および業務２のリクエスト識別子（ｐｉｄ１，ｔｉｄ２）が、実行中の業務のリクエスト識別子として記録されている。

図２０の業務実行優先度定義テーブル３２１、図２１の同時実行数調整比率定義テーブル４１０および図２２のリクエスト停止方法定義テーブル４２０は、リクエストを処理する前に予め定義されていた情報である。図２３のリクエストトレース３３１は、図１８の時点における各リクエストに対する業務処理の呼び出し階層をスタックで示している。図２４のアプリケーショントレース３４１は、図１８の時点におけるアプリケーション間の呼び出しの記録である。図２５のリソース使用状況テーブル５１０は、図１８の時点における各スレッドのＣＰＵ利用率およびメモリ使用量を示している。以下、リクエストを停止する処理の具体例について、停止業務の決定処理、停止リクエストの決定処理およびリクエストの停止処理の３つに分けて説明する（適宜図１８ないし図２５参照）。

＜停止業務の決定処理＞
（１）図１８に示す業務処理の状態で、プロセスＡのリソース使用量（ＣＰＵ利用率またはメモリ使用量）が閾値に達し、その旨をリソース監視部５０が業務停止部４０に通知する。
（２）業務停止部４０がリソース使用状況テーブル５１０（図２５参照）を取得する。
（３）業務実行状態管理テーブル３１１（図１９参照）から、リクエスト識別子が（ｐｉｄ１,ｔｉｄ１），（ｐｉｄ１，ｔｉｄ３）のものが業務１であり、（ｐｉｄ１，ｔｉｄ２）のものが業務２であると分かる。
（４）（３）で得た情報をリソース使用状況テーブル５１０（図２５参照）と照合して、業務１と業務２のリソース使用量は同じであると判断する。
（５）業務実行優先度定義テーブル３２１（図２０参照）を取得し、参照すると、業務１の実行優先度が低いので、リクエストを停止する対象は業務１となる。

＜停止リクエストの決定処理＞
（１）業務実行状態管理テーブル３１１（図１９参照）から、業務１の現在実行中のリクエストが２つあると分かる。
（２）同時実行数調整比率定義テーブル４１０（図２１参照）から、現在実行中のリクエストのうち５０％を削減する。従って、本例ではリクエストを１つ削減する。
（３）リクエスト停止方法定義テーブル４２０（図２２参照）から、停止するリクエストの選択方法が「３:スタックの深さ優先」なので、リクエストトレース３３１（図２３参照）を取得し、呼び出し階層（スタック）が深いものを停止対象のリクエストとする。従って、本例ではリクエスト識別子が（ｐｉｄ１，ｔｉｄ１）のものを停止対象とする。

＜リクエストの停止処理＞
（１）業務１の入口（本例ではアプリケーション１のメソッドａ）を閉塞する。プロセスのリソース使用量が閾値に達しているため、新しいリクエストは受け付けないはずだが、リクエスト停止中にリソース使用量が減り、新規にリクエストを受け付けてしまうのを防ぐために閉塞を行っている。
（２）リクエストトレース３３１（図２３参照）を取得し、（ｐｉｄ１，ｔｉｄ１）の現在実行中のスレッドから（スタックの上から）順に停止していく。つまり、本例ではアプリケーション２のメソッドｂ→アプリケーション１のメソッドａの順である。
（３）業務実行状態管理テーブル３１１（図１９参照）およびリクエストトレース３３１（図２３参照）から、リクエスト識別子が（ｐｉｄ１，ｔｉｄ１）のものを削除する。その結果、それぞれ図２６および図２７に示すようになる。

以上本発明の実施の形態について説明したが、図１に示す計算機１００のＣＰＵ１０で実行されるプログラム（処理実行数制御プログラムを含む）をコンピュータによる読み取り可能な記録媒体に記録し、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、本発明の実施の形態に係る処理実行数制御方法および計算機が実現されるものとする。なお、プログラムをインターネットなどのネットワーク経由でコンピュータシステムに提供するようにしてもよい。

以上本発明の好適な実施の形態について一例を示したが、本発明は前記実施の形態に限定されず、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。例えば、前記実施の形態では、プロセスのまたがりを１つの計算機１００に閉じたように記載したが、プロセスのまたがりが複数の計算機１００に亘るように構成してもよい。この場合には、スレッドを特定するために、プロセスＩＤおよびスレッドＩＤに加えて、計算機１００に固有なマシンＩＤを使用することになる。これによれば、複数のプロセスにまたがる複数のアプリケーションが複数の計算機に亘る場合であっても、業務処理の同時実行数を業務単位に制御することができる。

本発明の実施の形態に係る計算機の構成を示す図である。 業務実行状態管理テーブルの構成を示す図である。 業務実行優先度定義テーブルの構成を示す図である。 リクエストトレースの構成を示す図である。 アプリケーショントレースの構成を示す図である。 同時実行数調整比率定義テーブルの構成を示す図である。 リクエスト停止方法定義テーブルの構成を示す図である。 リソース使用状況テーブルの構成を示す図である。 リソース閾値定義テーブルの構成を示す図である。 計算機の初期化処理を示すフローチャートである。 計算機のリクエスト受信処理を示すフローチャートである。 リクエスト処理の詳細な動作を示すシーケンス図である。 停止対象の業務を決定する処理を示すフローチャートである。 停止対象のリクエストを決定する処理を示すフローチャートである。 アプリケーションの停止処理を示すフローチャートである。 トレース記録の遷移を示す図である。 トレース記録の遷移を示す図である。 所定の時刻における業務処理の状態を示す図である。 所定の時刻における業務実行状態管理テーブルの設定内容を示す図である。 業務実行優先度定義テーブルの事前の設定内容を示す図である。 同時実行数調整比率定義テーブルの事前の設定内容を示す図である。 リクエスト停止方法定義テーブルの事前の設定内容を示す図である。 所定の時点におけるリクエストトレースの設定内容を示す図である。 所定の時点におけるアプリケーショントレースの設定内容を示す図である。 所定の時点におけるリソース使用状況テーブルの設定内容を示す図である。 リクエスト停止後の業務実行状態管理テーブルの設定内容を示す図である。 リクエスト停止後のリクエストトレースの設定内容を示す図である。

符号の説明

１０ ＣＰＵ（処理部）
２０ 主記憶装置（記憶部）
１００ 計算機
３１１ 業務実行状態管理テーブル
３３１ リクエストトレース
５１０ リソース使用状況テーブル

Claims (10)

1. 送られた要求に対して業務処理を行う計算機が、その業務処理を複数のプロセスにまたがる複数のプログラムによって実行する場合に、前記業務処理の実行数を制御するプログラム制御方法であって、
   前記計算機の記憶部は、業務処理ごとのリソース使用量を管理し、
   前記計算機の処理部は、前記リソース使用量が所定の閾値を超えたときに、前記リソース使用量が最大である業務処理を停止する
   ことを特徴とするプログラム制御方法。
2. 送られた要求に対して業務処理を行う計算機が、その業務処理を複数のプロセスにまたがる複数のプログラムによって実行する場合に、前記業務処理の実行数を制御するプログラム制御方法であって、
   前記計算機の記憶部は、
   業務ごとに、実行中の業務処理に固有の処理ＩＤを管理し、
   前記処理ＩＤごとに、その処理ＩＤの業務処理を実行中の実行単位を管理し、
   前記業務処理の実行単位ごとに、リソース使用量を管理し、
   前記計算機の処理部は、前記リソース使用量が所定の閾値を超えたときに、
   前記実行単位ごとのリソース使用量を、前記実行単位を含む処理ＩＤごとに集計するステップと、
   前記集計した値を、前記処理ＩＤを含む業務ごとに合計し、その合計した値が所定値を超えた業務を、停止すべき業務として選択し、前記業務の処理ＩＤから、所定の選択条件によって、停止すべき処理ＩＤを選択するステップと、
   前記選択した処理ＩＤの業務処理を停止するステップと、
   を含んで実行する
   ことを特徴とするプログラム制御方法。
3. 前記リソース使用量は、前記記憶部であるメモリの使用量または前記処理部であるＣＰＵ（Central Processing Unit）の利用率であること
   を特徴とする請求項２に記載のプログラム制御方法。
4. 前記選択条件は、前記業務処理の実行単位が処理を開始した後、経過時間が長いことであること
   を特徴とする請求項２に記載のプログラム制御方法。
5. 前記選択条件は、外部からの要求の受付順が新しいことであること
   を特徴とする請求項２に記載のプログラム制御方法。
6. 前記選択条件は、実行中の業務処理のプロセス間のコールスタックが深いことであること
   を特徴とする請求項２に記載のプログラム制御方法。
7. 前記選択条件は、
   実行中の業務処理の数と、予め前記記憶部に設定された削減割合とを掛け合わせた値を、停止すべき業務処理の数とすることであること
   を特徴とする請求項２に記載のプログラム制御方法。
8. 前記選択した処理ＩＤの業務処理を停止するステップにおいて、
   前記停止すべき業務に係る要求に対しては、その要求元にエラーメッセージを送信するとともに、
   停止すべき業務処理の実行単位を、実行中の実行単位から順に停止する
   ことを特徴とする請求項２に記載のプログラム制御方法。
9. 送られた要求に対して業務処理を行うとともに、その業務処理を複数のプロセスにまたがる複数のプログラムによって実行する場合に、前記業務処理の実行数を制御する計算機であって、
   前記計算機の記憶部は、
   業務ごとに、実行中の業務処理に固有の処理ＩＤを管理し、
   前記処理ＩＤごとに、その処理ＩＤの業務処理を実行中の実行単位を管理し、
   前記業務処理の実行単位ごとに、リソース使用量を管理し、
   前記計算機の処理部は、前記リソース使用量が所定の閾値を超えたときに、
   前記実行単位ごとのリソース使用量を、前記実行単位を含む処理ＩＤごとに集計し、
   前記集計した値を、前記処理ＩＤを含む業務ごとに合計し、その合計した値が所定値を超えた業務を、停止すべき業務として選択し、前記業務の処理ＩＤから、所定の選択条件によって、停止すべき処理ＩＤを選択し、
   前記選択した処理ＩＤの業務処理を停止する
   ことを特徴とする計算機。
10. コンピュータに請求項１ないし請求項８のいずれか一項に記載のプログラム制御方法を実行させることを特徴とするプログラム制御プログラム。

Images