JP6823670B2 - 複雑なシステムにおけるボトルネックの検出及び予測 - Google Patents

Description

本発明は、一般に、システムにおけるボトルネックを検出するための方法に関し、より具体的には、ノードがソフトウェア・モジュールを表し、グラフのエッジ（edge）が通信チャネルを表すグラフを用いる方法に関する。本発明はさらに、システムにおけるボトルネックを検出するためのボトルネック識別システム及びコンピュータ・プログラム製品に関する。

今日、ソフトウェア解決法は、多数の相互通信するエンドポイントから構成されることが多々あり、そこで、多数のエンドポイントは、同時に、データ・プロデューサ及び消費者として機能する。エンドポイント／ソフトウェア・モジュールの１つにおける性能不良が生じることがあり、これは、一般的に、完全な解決法の性能全体に影響を与える。さらに、エンドポイントの性能は、それを実行しているハードウェアだけではなく、例えば、物理マシンであることも又は仮想マシンであることもある同じマシン上で実行されている他のソフトウェア・モジュールのような他の要因にも左右される。特に断続的に存在する場合、システムにおけるボトルネックの根本原因の特定（isolating）は、検出し、特定し、排除するのが困難であり得る。その理由は、性能ボトルネックには複数の理由があり得るという事実のためである。例えば、主メモリ又は外部ストレージ容量などのコンピューティング・リソースが十分でない、スワップ・ファイルが大きすぎる又は小さすぎる、通信帯域幅が十分でない、同じソフトウェア・モジュールで同じことをしようと試みるユーザが多すぎる等が発生し得る。経験を積んだシステム設計者及びアーキテクチャ設計者にとってさえ、性能上の問題の真の原因に取り組むのは、厄介な作業である得る。こうした分析をサポートするツールの数は、依然として限られており、多くの場合、過去の静的な情報に基づいている。

従って、システムにおけるボトルネックを特定する際のより高度なサポートに対する要件があり得る。

本明細書で開示されるように、システムにおけるボトルネックを検出するための、コンピュータにより実行される方法が、グラフを受信することであって、ノードはソフトウェア・モジュールを表し、エッジはソフトウェア・モジュール間の通信チャネルを表す、受信することと、利用可能なリソースと比較して、各ソフトウェア・モジュールについて選択されたリソース（selected resource）を監視することと、通信チャネル上で消費される帯域幅対利用可能な帯域幅の比を監視することと、生成される出力量が、アイドル・モードにあるソフトウェア・モジュールが必要とする出力量を下回るソース・ソフトウェア・モジュールを識別するためにグラフをトラバースすることと、識別したソース・ソフトウェア・モジュールのリソース消費を分析して、識別したソース・ソフトウェア・モジュールについてのリソースの不足量を識別することと、を含む。上記の方法に対応するコンピュータ・システム及びコンピュータ・プログラム製品も本明細書に開示される。

本発明の実施形態による、システムにおけるボトルネックを検出するための本発明の方法の例を示すブロック図である。 本発明の実施形態による、本発明の方法の一般的なモデルの例を示すグラフである。 本発明の実施形態による、ネットワークの要素を含むシステムの例を示すブロック図である。 本発明の実施形態による、システムにおけるボトルネックを検出するためのボトルネック検出システムの例を示すブロック図である。 システムにおけるボトルネックを検出するためのシステムを含むコンピューティング・システムの実施形態を示す。

本発明の１つの態様によると、システムにおけるボトルネックを検出するための方法を提供することができる。システムは、通信チャネルを介して互いに通信するソフトウェア・モジュールを含むことができる。方法は、グラフを受信することを含むことができる。グラフにおいて、ノードは、ソフトウェア・モジュールの１つを表し、エッジは、ソフトウェア・モジュールの内の送信ソフトウェア・モジュール（transmitting software module）から、ソフトウェア・モジュールの内の受信ソフトウェア・モジュール（receiving software module）へのデータ・フローを有する通信チャネルの１つを表すことができる。ソフトウェア・モジュールを表すノードは、送信ソフトウェア・モジュール及び受信ソフトウェア・モジュールとして機能し、受信する入力データの量対入力データから導かれる生成される出力データの量の予測される比を表す所定の係数に関連し得る。

方法は、各ソフトウェア・モジュールについて、選択されたリソースについて、ソフトウェア・モジュールにより消費されるリソースの量対利用可能なリソースの量の比を監視することと；各通信チャネルについて、通信チャネルの１つにより消費される帯域幅対通信チャネル上の利用可能な帯域幅の比及び通信チャネルのアイドル時間の量を監視することと；アイドル・モードにあるソフトウェア・モジュールについて、生成される出力量が、アイドル・モードにあるソフトウェア・モジュールが必要とする出力量を下回るソース・ソフトウェア・モジュールを識別するためにグラフをトラバースすることと；識別したソース・ソフトウェア・モジュールのリソース消費を分析して、識別したソース・ソフトウェア・モジュールについてのリソースの不足量を識別することと、をさらに含むことができる。

本発明の別の態様によると、システムにおけるボトルネックを検出するためのボトルネック識別システムを提供することができる。また、システムは、通信チャネルを介して互いに通信するソフトウェア・モジュールを含むことができる。システムは、グラフを受信するように適合された受信ユニットを含むことができ、ノードはソフトウェア・モジュールの１つを表し、エッジは、ソフトウェア・モジュールの内の送信ソフトウェア・モジュールからソフトウェア・モジュールの内の受信ソフトウェア・モジュールへのデータ・フローを有する通信チャネルの１つを表すことができる。ソフトウェア・モジュールを表すノードは、特に、同時に送信ソフトウェア・モジュール及び受信ソフトウェア・モジュールとして機能することができ、受信する入力データの量対入力データから導かれる生成される出力データの量の予測される比を表す所定の係数に関連し得る。システムは、各ソフトウェア・モジュールについて、選択されたリソースについて、ソフトウェア・モジュールにより消費されるリソースの量対利用可能なリソースの量の比を監視するように適合された監視ユニットをさらに含むことができる。監視ユニットはまた、各通信チャネルについて、通信チャネルの１つにより消費される帯域幅対利用可能な通信チャネルの帯域幅の比及び通信チャネルのアイドル時間の量を監視するようにも適合することができる。トラバース・モジュールは、アイドル・モードにあるソフトウェア・モジュールについて、生成される出力量が、アイドル・モードにあるソフトウェア・モジュールが必要とする出力量を下回るソース・ソフトウェア・モジュールを識別するためにグラフをトラバースするように適合することができ、分析モジュールは、識別したソース・ソフトウェア・モジュールのリソース消費を分析して、識別したソース・ソフトウェア・モジュールについてのリソースの不足量を識別するように適合することができる。

さらに、実施形態は、コンピュータ又はいずれかの命令実行システムによって又はこれと関連して使用するためのプログラム・コードを提供するコンピュータ使用可能又はコンピュータ可読媒体からアクセス可能な関連したコンピュータ・プログラム製品の形を取ることができる。この説明の目的のため、コンピュータ使用可能又はコンピュータ可読媒体は、命令実行システム、装置、若しくはデバイスによって又はこれと関連して使用するためのプログラムを格納、通信、伝搬、又は伝送するための手段を含むことができる任意の装置とすることができる。

本発明の実施形態は、異なる主題に関連して説明されることに留意されたい。特に、幾つかの実施形態は、方法タイプの請求項（method type claim）に関連して説明されている一方で、他の実施形態は、装置タイプの請求項（apparatus type claim）に関連して説明される。しかしながら、当業者であれば、特に明記されていない限り、上記及び以下の説明から、１つのタイプの主題に属する特徴の任意の組み合わせに加えて、異なる主題に関係する特徴の間の、特に方法タイプの請求項の特徴と装置タイプの請求項の特徴との間の任意の組み合わせは、本文書内で開示されるものと見なされることを推測するであろう。

上記に定められる態様、及び本発明のさらなる態様は、以下で説明される実施形態の例から明らかであり、実施形態の例を参照して説明されるが、本発明は、それらに限定されるものではない。

本説明の文脈において、以下の規則、用語、及び／又は表現を用いることができる。

用語「ボトルネック」は、例えば、その一部がソフトウェア・モジュールであり得る一連のモジュールを含むシステムの性能に関する何らかの悪影響を示し得る。ボトルネックという用語は、性能低下という用語に置き換えることができる。性能上の問題の理由は明らかでないことがあり、徹底的な分析を必要とすることがある。

用語「システム」は、ソフトウェア・モジュール、何らかの種類のハードウェア・コンポーネント、通信ユニット、ストレージ要素等のような、相互関連したアイテムの群を示すことができ、全てがコンピューティング及び通信システムの一部である。

用語「ソフトウェア・モジュール」は、上に定義したようなシステムの一部であるソフトウェア・コンポーネントを示すことができる。ソフトウェア・モジュールは、アプリケーション・ソフトウェア、システム・ソフトウェア、ミドルウェア・ソフトウェア、埋め込まれたソフトウェア、通信ソフトウェア等のような、いずれかの種類のソフトウェア・モジュールとすることができる。ソフトウェア・モジュールの種類への制限はないことがある。ソフトウェアは、少なくとも、データを受信するための入力ポートと、データを出力するための出力ポートとを含むことができる。ソフトウェア・モジュール自体は、データをいずれかの形に変換し、それらを格納し、及び／又は出力ポートに送ることができる。

用語「通信チャネル」は、データ出力及びデータ入力を接続するデータ・リンクを示すことができる。データ出力は、ソフトウェア・モジュールの形、及び／又は代替的にハードウェア・モジュールの形の出力とすることができる。また、組み合わせも可能である。

用語「グラフ」は、数学的に、より具体的には、グラフ理論において、オブジェクトの幾つかの対がリンクにより接続される、オブジェクトの集合の表示を示すことができる。相互接続されるオブジェクトは、頂点と呼ばれる（ノード又は点（point）とも呼ばれる）数学的抽象化により表され、頂点の幾つかの対を接続するリンクは、エッジと呼ばれる（弧又は線と呼ばれることもある）。一般的に、グラフは、エッジの線又は曲線により結合される頂点のドットの集合として線図の形で示される。

用語「ノード」は、上述したグラフの定義の意味におけるオブジェクトを示すことができる。「エッジ」という用語は、上述したグラフの定義の意味におけるリンクを示すことができる。

用語「送信ソフトウェア・モジュール」は、ソフトウェア・モジュールからデータを送るソフトウェア・モジュールを示すことができる。用語「受信ソフトウェア・モジュール」は、用語「送信ソフトウェア・モジュール」の反対を示し得る。ソフトウェア・モジュールは、同時に送信及び受信の両方の特徴を有し得ることに留意されたい。

用語「選択されたリソース」は、オブジェクト又はリンクのタスクを実行するために使用される任意のリソース、すなわち、本発明の意味及びグラフ理論におけるソフトウェア・モジュール又は通信チャネルを示すことができる。選択されたリソースは、利用可能なメモリの量及び速度、ストレージ、ＣＰＵパワー、クロック速度、バスクロック速度、ＣＰＵ毎のコア、コア毎のスレッドの数、Ｉ／Ｏ率等を含むことができるが、これらに限定されない。

用語「マイクロ・サービス（micro-service）」は、特殊な形のソフトウェア・モジュールを示すことができる。クラウド・コンピューティングにおいて、ソフトウェア・モジュール及び完全なシステムは、マイクロ・サービスから、すなわち、全体機能のうちの部分機能のみを含む小さな相互接続されたソフトウェア・モジュールから構築することができる。

システムにおけるボトルネックの検出及びボトルネックの識別のための提案される方法は、複数の利点及び技術的効果をもたらすことができる。

提案される解決法は、ＣＰＵ、コプロセッサ、キャッシュ・メモリ、主メモリ、Ｉ／Ｏデバイス、データベース、ユーザ・インターフェース、通信リンク、それらの量及び可用性等のようなリソースを連続的に監視することができる。リソース自体に加えて、各ノード及び各データ・フローについてのリソース、すなわちノードへの／これからの通信チャネルについてのリソースの消費を監視することができる。リンク又は通信チャネルは、ソフトウェア・モジュールの間に確立することができ、その適切な機能のために必要とされるリソースを監視することができる。このように、システム内の個々の活動のリソース要件から、非常に精密な図を描くことができる。これは、ボトルネックの詳細な分析及びその排除のための基礎になり得る。所定の値又は比に対する測定した値又はリソース消費をマッピングする能力は、単一の又は複数の閾値ベースの警告及び最適化システムを可能にできる。

提案される解決法は、ソフトウェア・コンポーネントの１つ１つのコンポーネント及び通信リンクにおけるボトルネックを識別することができる。性能低下の根本原因を検出し、将来のこうしたボトルネックを回避するためにアクションをとることができる。操作者は、ボトルネックを検出するための提案される方法及び／又はシステムにより積極的なサポートを得ることができる。この解決法の動的特性のため、操作者は、性能分析のために履歴データに依存する必要はない。代わりに、操作者は、ソフトウェア・モジュール及び通信チャネルのシステムからのライフ・データによりイネーブルにされ得る。

システム・ボトルネックを特定し、最終的に排除するために、グラフ理論を用いるこの新しい手法により、新しいレベルのシステム最適化を達成することができる。

本方法の１つの好ましい実施形態よると、ノードは、データ・ソース、例えば、データベース、データ・ストレージ、又は別のソフトウェア・モジュール、データ処理システム、データ変換システム、特に処理ソフトウェア・モジュール、及びユーザ・インターフェース・モジュールを含む群から選択することができる。ネットワーク・モジュール、ミドルウェア・モジュール、ストレージ・モジュール等から、他の随意的なノード・タイプを選択することもできる。従って、コンピューティング・システムの任意のコンポーネント、特にソフトウェア・ベースのノードを、データのソース及びシンクとして使用することができる。従って、提案される解決法は、事実上、あらゆるシステム・アーキテクチャ及び構成に適合可能である。

本方法の１つの好ましい実施形態よると、データ・ソースは、データベース、ファイル・システム、コンテンツ管理システム、又はストリーミング・データとすることができる。データは、有線ベース又は無線で供給され得る。従って、提案される方法は、モバイル技術及び／又はクラウド・システムによりリンクされたソフトウェア・モジュールを含むシステムでも使用可能である。また、本方法により、埋め込まれたシステムをサポートすることもできる。

本方法の１つの許容的実施形態によると、ソフトウェア・モジュールの少なくとも１つは、マイクロ・サービスとすることができる。或いは言い換えると、本方法により、全てのタイプのソフトウェア・モジュールを、システムのノードとしてサポートすることができる。

本発明の１つの有利な実施形態によると、リソース消費を分析することは、ある期間にわたってリソースのサポート不足（lacking support）を追跡し、報告することを含むことができる。所定の時間におけるこの発生を観測することができる。ボトルネックは、時間と共にゆっくりと増大することがある。時系列ベースの分析は、ボトルネックの根本原因をずっと早く識別するのを助けることができる。

本方法の付加的に好ましい実施形態によると、リソース消費を分析することは、リソースのサポート不足を防止する勧告を決定することを含むことができる。このために、他のシステムから知られる典型的なシステム・ボトルネックを備えた知識ベースが存在し得る。異なるリソースのリソース不足の組み合わせを結合し、実際のリソース測定値及び知識ベースにおいて利用可能なものを用いて、パターン照合を適用することができる。従って、操作者は、分析自体を行うことなく、システム最適化に対する直接的な勧告を得ることができる。

知識ベースを介したボトルネックの排除の経験を共有し、そのように拡張された知識ベースを他の操作者が利用できるようにすることにより、知識及びノウハウを広め、その知識ベースのコンテンツを共有するそれらの実施の自己学習環境を示すことができる。

本方法の１つの許容的実施形態によると、リソース消費を分析することは、ソフトウェア・モジュールを異なるコンピューティング・システムに移動することを含むことができる。このことは、性能全体に大きな影響を及ぼし得る。異なるコンピューティング・システムがより多くの利用可能なリソースを有することができる場合又は完全に使用されていない場合には、ごくわずかな通信オーバーヘッドしか必要としない。しかしながら、ソフトウェア・モジュールが非常にリソース集約型であり（例えば、ソフトウェア・モジュールが数値演算アプリケーション・モジュールとすることができるので）、従って、オリジナルのコンピューティング・システム上の競合するソフトウェア・モジュールと競合し得る場合、空いており使用されていないコンピューティング・システムへの移行は、ソフトウェア・モジュールのシステムの性能全体を劇的に増大させ得る。

本発明の別の好ましい実施形態によると、リソース消費を分析することは、システムがリソースの変化にどのように反応するかを予測することを含むことができる。これは、コンポーネント又はリソースの可用性、量、又は速度を含むことができる。これは、同じリソースについての競合するソフトウェア・モジュールの変化を反映させることを含むこともできる。このため、方法が、同じコンピューティング・システム上のリソース不足をめぐって競合する別のソフトウェア・モジュールを追跡し、報告することを含むことができることが必要とされることがある。従って、これは、複数のソフトウェア・モジュールを含むシステムからボトルネックを排除するための極めて強力な最適化技術であり得る。

以下に、図の詳細な説明が提供される。図における全ての指示は概略である。最初に、システムにおけるボトルネックを検出するための本発明の方法の実施形態のブロック図が与えられる。その後、更に別の実施形態、並びに、システムにおけるボトルネックを検出するためのボトルネック識別システムの実施形態が説明される。

図１は、システムにおけるボトルネックを検出するための方法１００のブロック図を示す。システムは、コンピュータ・システム、周辺デバイスが取り付けられたコンピュータ・システム、コンピュータのネットワーク、複数のマイクロ・サービス、完全なソフトウェア・アプリケーション・システム等とすることができる。システムは、通信チャネルを介して互いに通信する、少なくとも１つのソフトウェア・モジュール、特に複数のソフトウェア・モジュールを含む。これらのソフトウェア・モジュールは、システム・レベル・パイプ、ソケット等とすることができ、当業者には周知である。方法は、グラフを受信すること（１０２）を含む。ノードは、ソフトウェア・モジュールの１つを表し、エッジは、ソフトウェア・モジュールの内の送信ソフトウェア・モジュールからソフトウェア・モジュールの内の受信ソフトウェア・モジュールへのデータ・フローを有する通信チャネルの１つを表す。ソフトウェア・モジュールを表し、同時に送信ソフトウェア・モジュール及び受信ソフトウェア・モジュールとして機能するノードは、受信する入力データの量対入力データから導かれる生成される出力データの量の予測される比を表す所定の係数に関連する。

方法はまた、各ソフトウェア・モジュールについて、選択されたリソースについて、例えばＲＡＭの量、ＣＰＵの数、コア、スレッド、コプロセッサ、他のアクセラレータ、Ｉ／Ｏ率、ＣＰＵ毎の並列スレッド等について、ソフトウェア・モジュールにより消費されるリソースの量対利用可能なリソースの量の比を監視すること（１０４）も含む。

方法はさらに、各通信チャネルについて、通信チャネルの１つにより消費される帯域幅対通信チャネルの利用可能な帯域幅の比及び通信チャネルのアイドル時間の量を監視すること（１０６）と、アイドル・モードにあるソフトウェア・モジュールについて、生成される出力量が、アイドル・モードにあるソフトウェア・モジュールが必要とする出力量を下回るソース・ソフトウェア・モジュールを識別するためにグラフをトラバースする（traverse; グラフを横断して調べる）こと（１０８）とを含むことができる。この方法は、識別したソース・ソフトウェア・モジュールのリソース消費を分析して、識別したソース・ソフトウェア・モジュールについてのリソースの不足量を識別すること（１１０）を含む。このように、上述した全ての利点をもたらすことができる。

図２は、現在提案される概念についての一般的なモデルとして有用なグラフ２００の例を示す。グラフ２００は、グラフの数学的概念の意味の例示的なノード２０２、２０４、２０６、２０８、２１０、２１２、２１４を含む。ノード２０２、・・・２１４の中間に、リンク２１６、２１８、２２０、２２２、２２４、２２６及び２２８がある。リンクは、ノード間の情報の伝達を可能にする通信リンク又は通信チャネルとして解釈することができる。ノードは、本出願の文脈において、ソフトウェア・モジュールとして解釈することができる。

図３は、ネットワーク３００の要素を含むシステムの実施形態のブロック図を示す。これは、現実のアプリケーション３０２に対するグラフ概念のアプリケーションと見なすことができる。

参照番号３０４、３０６及び３０８で表されるソフトウェア・モジュールがある場合がある。ソフトウェア・モジュール３０６は、例えば、データベースのようなデータ・ストレージを表すことができる。通信チャネル３１２は、ソフトウェア・モジュール３０６の送信部からソフトウェア・モジュール３０４の受信部にデータを転送することができる。ソフトウェア・モジュール３０４は、処理モジュール３０４又はトランザクション・モジュール３０４を表すことができ、送信部を用いて、処理モジュール３０４から、ユーザ・インターフェースを表すことができるソフトウェア・モジュール３０８にデータを送ることができる。通信チャネル３１０を用いて、データを送ることができる。

ノード３０４、３０６、３０８で表されるソフトウェア・モジュールのこのサンプル・ネットワークは２つの通信チャネル３１２及び３１０しか有していないが、動的な性能上の問題又はボトルネックを検出し、特定し、排除することは極めて困難であり得る。これは、ユーザ・インターフェース・ソフトウェア・モジュール３０８からトランザクション・ソフトウェア・モジュール３０４への通信チャネル３１４のフィードバック・ループにより示すことができる。

実際に、相互依存するソフトウェア・モジュールのネットワークは、極めて大きいものであり、より多くのノード、すなわちソフトウェア・モジュール、及びより多くのリンク、すなわち通信チャネルを含むことができる。しかしながら、このより簡単なモデルを用いて、基本的な本発明の概念を示すことができる。

現在の実施形態において、処理ソフトウェア・モジュール３０４及びユーザ・インターフェース・ソフトウェア・モジュールが同じマシンを占有し、ＩＰＣ（例えばＵＮＩＸドメイン・ソケットなどのプロセス間通信）を介して通信すると仮定することができる。あらゆるソフトウェア・モジュールが別個のコンピュータ上で実行されることを必要としないこともある。

提案される解決法は、各ノード又はソフトウェア・モジュールについてのリソース（上述のような）の消費量、及びデータベース３０６のような、その一部が送信器のみであり得るノード又はソフトウェア・モジュールへの／からのデータ・フローを絶えず監視する。他のソフトウェア・モジュールは、例えばユーザ・インターフェース・ソフトウェア・モジュールなど、受信器のみである又は大部分が受信器であり得る。

ユーザ・インターフェース（ＵＩ）ソフトウェア・モジュール３０８を監視し、これがデータを待っていると判断した場合、処理ソフトウェア・モジュール３０４もデータを待っていると判断することができる。この状況から、ＵＩソフトウェア・モジュール３０８及び処理ソフトウェア・モジュール３０４は、データベース（ＤＢ）ソフトウェア・モジュール３０６からのデータを待っており、それがグラフ３００のエンドポイントであるため、他のいずれのコンポーネント又はソフトウェア・モジュールからデータを待つことはできないと判断することができる。従って、ＤＢソフトウェア・モジュール３０６は、潜在的なボトルネックを有する。さらなる試験又は測定基準及び分析により、ディスクＩ／Ｏは、ケースのほぼ１００％で用いられるリソースであることが明らかになり得る。従って、ＤＢソフトウェア・モジュール３０６に関連するリソース・ディスクのＩ／Ｏ率を増大させるためにアクションを取るよう、勧告が生成される。操作者への関連したメッセージは、このように見える：「ＤＢは、集中的Ｉ／Ｏに起因してボトルネック・コンポーネントを有するように見える。マシン上の２番目に大きいＩ／Ｏ消費者は、Ａｐａｃｈｅと呼ばれるプロセスである（Ｉ／Ｏ利用率１０％）。実行可能である場合、リソースを停止若しくは制限すること、又はそれを別のコンピュータ・システムに移動させることを考えることができる。」

同じ実施形態に関連する別の例において、ＵＩソフトウェア・モジュール３０８は待機中であり、また、ＤＢソフトウェア・モジュール３０６は、大部分がアイドル状態である。これから、処理ソフトウェア・モジュール３０４はボトルネックである可能性があるとの直接的結論が出される。従って、ＤＢソフトウェア・モジュール３０６は、処理ソフトウェア・モジュール３０４がそれを消費できるよりも迅速にデータを生成することができ、及び／又はＵＩソフトウェア・モジュール３０８は、処理ソフトウェア・モジュール３０４がそれを伝送できるよりも迅速にデータを受信することができる。リソース使用分析により、処理ソフトウェア・モジュール３０４は、ＲＡＭリソースから見ると、ＵＩソフトウェア・モジュール３０８と競合することが明らになる。次に、ボトルネック識別システムは、ＲＡＭの量を増加させる、又はソフトウェア・モジュール３０８若しくは処理ソフトウェア・モジュール３０４を別の物理コンピュータ・システムに移動する勧告を有する、操作者へのメッセージを生成することができる。この簡単化した例及び実施形態に基づいて、当業者であれば、より複雑なシナリオを導き出すことができる。

図４は、通信チャネルを介して互いにリンクされたソフトウェア・モジュールを含むシステムにおけるボトルネックを検出するための本発明のボトルネック識別システム４００の実施形態を示す。ボトルネック識別システムは、グラフを受信するように適合された受信ユニット４０２を含む。各ノードは、ソフトウェア・モジュールの１つを表し、エッジは、ソフトウェア・モジュールの内の送信ソフトウェア・モジュールからソフトウェア・モジュールの内の受信ソフトウェア・モジュールまでのデータ・フローを有する通信チャネルの１つを表す。ノードは、送信ソフトウェア・モジュール及び受信ソフトウェア・モジュールとして機能するソフトウェア・モジュールを表すことができる。各ノードは、受信する入力データの量対入力データから導かれる生成される出力データの量の予測される比を表す所定の係数に関連し得る。

ボトルネック識別システム４００は、各ソフトウェア・モジュールについて、ソフトウェア・モジュールにより消費されるリソースの量対利用可能なリソースの量の比を監視するように適合された監視ユニット４０４も含む。監視ユニット４０４はまた、各通信チャネルについて、通信チャネルの１つにより消費される帯域幅対利用可能な通信チャネルの帯域幅の比及び通信チャネルのアイドル時間の量を監視するようにも適合される。トラバース・モジュール４０６は、アイドル・モードにあるソフトウェア・モジュールについて、それをビジーに保持するように、生成される出力量が、アイドル・モードにあるソフトウェア・モジュールが必要とする出力量を下回るソース・ソフトウェア・モジュールを識別するためにグラフをトラバースするように適合される。分析モジュール４０８は、識別したソース・ソフトウェア・モジュールのリソース消費を分析して、識別したソース・ソフトウェア・モジュールについてのリソースの不足量を識別するように適合される。

本発明の実施形態は、プログラム・コードを格納及び／又は実行するのに適したプラットフォームに関係なく、事実上、あらゆるタイプのコンピュータと共に実施することができる。

図５は、提案される方法に関連するプログラム・コードを実行するのに適したコンピューティング・システム５００を例として示す。コンピューティング・システム５００は、好適なコンピュータ・システムの一例にすぎず、本明細書で説明される本発明の実施形態の使用範囲又は機能に関する何らかの制限を示唆することを意図するものではない。それにも関わらず、コンピュータ・システム５００は、上述した機能のいずれかを実装及び／又は実行することができる。コンピュータ・システム５００において、多数の他の汎用又は専用コンピューティング・システム環境又は構成で動作するコンポーネントがある。コンピュータ・システム／サーバ５００と共に使用するのに好適であり得る周知のコンピューティング・システム、環境、及び／又は構成の例として、これらに限定されるものではないが、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、手持ち式又はラップトップ型デバイス、マルチプロセッサ・システム、マイクロプロセッサ・ベースのシステム、セット・トップ・ボックス、プログラム可能民生電子機器、ネットワークＰＣ、ミニコンピュータ・システム、メインフレーム・コンピュータ・システム、及び、上述のシステム若しくはデバイスのいずれかを含む分散型クラウド・コンピューティング環境等が含まれる。コンピュータ・システム／サーバ５００は、コンピュータ・システム５００によって実行される、プログラム・モジュールなどのコンピュータ・システム実行可能命令の一般的な文脈で説明することができる。一般に、プログラム・モジュールは、特定のタスクを実行する又は特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、論理、データ構造などを含むことができる。コンピュータ・システム／サーバ５００は、通信ネットワークを通じてリンクされた遠隔処理デバイスによってタスクが実行される分散型クラウド・コンピューティング環境で実施することができる。分散型クラウド・コンピューティング環境において、プログラム・モジュールは、メモリ・ストレージ・デバイスを含む、ローカル及び遠隔両方のコンピュータ・システム・ストレージ媒体内に配置することができる。

図に示されるように、コンピュータ・システム／サーバ５００は、汎用コンピューティング・デバイスの形で示される。コンピュータ・システム／サーバ５００のコンポーネントは、これらに限定されるものではないが、１つ又は複数のプロセッサ又は処理ユニット５０２、システム・メモリ５０４、及びシステム・メモリ５０４を含む種々のシステム・コンポーネントをプロセッサ５０２に結合するバス５０６を含むことができる。バス５０６は、メモリ・バス又はメモリ・コントローラ、周辺バス、アクセラレーテッド・グラフィックス・ポート、及び種々のバス・アーキテクチャのいずれかを用いるプロセッサ又はローカル・バスを含む、幾つかのタイプのバス構造のうちのいずれかの１つ又は複数を表す。限定ではなく例としては、このようなアーキテクチャは、業界標準アーキテクチャ（Industry Standard Architecture、ＩＳＡ）バス、マイクロ・チャネル・アーキテクチャ（Micro Channel Architecture、ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカル・バス、及びＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスを含む。コンピュータ・システム／サーバ５００は、典型的には、種々のコンピュータ・システム可読媒体を含む。このような媒体は、コンピュータ・システム／サーバ５００によりアクセス可能ないずれかの利用可能媒体とすることができ、揮発性媒体及び不揮発性媒体の両方と、取り外し可能媒体及び取り外し不能媒体の両方とを含む。

システム・メモリ５０４は、ランダム・アクセス・メモリ（ＲＡＭ）５０８及び／又はキャッシュ・メモリ５１０など、揮発性メモリの形のコンピュータ・システム可読媒体を含むことができる。コンピュータ・システム／サーバ５００は、他の取り外し可能／取り外し不能、揮発性／不揮発性のコンピュータ・システム・ストレージ媒体をさらに含むことができる。単なる例として、取り外し不能の不揮発性磁気媒体（図示されておらず、典型的には「ハード・ドライブ」と呼ばれる）との間の読み出し及び書き込みのために、ストレージ・システム５１２を設けることができる。図示されていないが、取り外し可能な不揮発性磁気ディスク（例えば、「フロッピー・ディスク」）との間の読み出し及び書き込みのための磁気ディスク・ドライブと、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ又は他の光媒体などの取り外し可能な不揮発性光ディスクとの間の読み出し及び書き込みのための光ディスク・ドライブとを設けることができる。このような例においては、それぞれを、１つ又は複数のデータ媒体インターフェースによってバス５０６に接続することができる。以下でさらに示され説明されるように、メモリ５０４は、本発明の実施形態の機能を実行するように構成されたプログラム・モジュールのセット（例えば、少なくとも１つ）を有する少なくとも１つのプログラム製品を含むことができる。

限定ではなく例として、メモリ５０４内に、プログラム・モジュール５１６のセット（少なくとも１つ）を有するプログラム／ユーティリティ５１４、並びにオペレーティング・システム、１つ又は複数のアプリケーション・プログラム、他のプログラム・モジュール、及びプログラム・データを格納することができる。オペレーティング・システム、１つ又は複数のアプリケーション・プログラム、他のプログラム・モジュール、及びプログラム・データ、又はそれらの何らかの組み合わせの各々は、ネットワーキング環境の実装形態を含むことができる。プログラム・モジュール５１６は、一般に、本明細書で説明される本発明の実施形態の機能及び／又は方法を実行する。

コンピュータ・システム／サーバ５００は、キーボード、ポインティング・デバイス、ディスプレイ５２０等のような１つ又は複数の外部デバイス５１８；ユーザがコンピュータ・システム／サーバ５００と対話することを可能にする１つ又は複数のデバイス；及び／又はコンピュータ・システム／サーバ５００が１つ又は複数の他のコンピューティング・デバイスと通信することを可能にするいずれかのデバイス（例えば、ネットワーク・カード、モデムなど）と通信することもできる。このような通信は、入力／出力（Ｉ／Ｏ）インターフェース５１４を経由して行うことができる。さらにまた、コンピュータ・システム／サーバ５００は、ネットワーク・アダプタ５２２を介して、ローカル・エリア・ネットワーク（ＬＡＮ）、汎用広域ネットワーク（ＷＡＮ）、及び／又はパブリック・ネットワーク（例えば、インターネット）などの１つ又は複数のネットワークと通信することもできる。示されるように、ネットワーク・アダプタ５２２は、バス５０６を介して、コンピュータ・システム／サーバ５００の他のコンポーネントと通信する。図示されないが、コンピュータ・システム／サーバ５００と共に他のハードウェア及び／又はソフトウェア・コンポーネントを使用できることを理解されたい。例としては、これらに限定されるものではないが、マイクロコード、デバイス・ドライバ、冗長処理ユニット、外部のディスク・ドライブ・アレイ、ＲＡＩＤシステム、テープ・ドライブ、及びデータ・アーカイブ・ストレージ・システムなどが含まれる。

付加的に、システムにおけるボトルネックを検出するためのボトルネック識別システム４００をバス・システム５０６に取り付けることができる。

本発明の種々の実施形態の説明は、例証の目的のために提示されたが、これらは、網羅的であること、又は本発明を開示した実施形態に限定することを意図するものではない。当業者には、説明される実施形態の範囲及び趣旨から逸脱することなく、多くの修正及び変形が明らかであろう。本明細書で用いられる用語は、実施形態の原理、実際の適用、又は市場に見られる技術に優る技術的改善を最もよく説明するため、又は、当業者が、本明細書に開示される実施形態を理解するのを可能にするために選択された。

本発明は、システム、方法、及び／又はコンピュータ・プログラム製品とすることができる。コンピュータ・プログラム製品は、プロセッサに本発明の態様を実行させるためのコンピュータ可読プログラム命令をその上に有するコンピュータ可読ストレージ媒体（単数又は複数）を含むことができる。

媒体は、伝搬媒体のための、電子、磁気、光学、電磁気、赤外線又は半導体のシステムとすることができる。コンピュータ可読媒体の例として、半導体又はソリッド・ステート・メモリ、磁気テープ、取り外し可能なコンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、剛性磁気ディスク及び光ディスクが挙げられる。光ディスクの現在の例として、コンパクト・ディスク−読み出し専用メモリ（ＣＤ−ＲＯＭ）、コンパクト・ディスク−読み出し／書き込み（ＣＤ−Ｒ／Ｗ）、ＤＶＤ、及びブルーレイ・ディスク（Blu-Ray-Disk）が挙げられる。

コンピュータ可読ストレージ媒体は、命令実行デバイスにより使用される命令を保持及び格納できる有形デバイスとすることができる。コンピュータ可読ストレージ媒体は、例えば、これらに限定されるものではないが、電子ストレージ・デバイス、磁気ストレージ・デバイス、光ストレージ・デバイス、電磁気ストレージ・デバイス、半導体ストレージ・デバイス、又は上記のいずれかの適切な組み合わせとすることができる。コンピュータ可読ストレージ媒体のより具体的な例の非網羅的なリストとして、以下のもの：すなわち、ポータブル・コンピュータ・ディスケット、ハードディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能プログラム可能読み出し専用メモリ（ＥＰＲＯＭ又はフラッシュ・メモリ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）、ポータブル・コンパクト・ディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）、メモリ・スティック、フロッピー・ディスク、パンチカード若しくは命令がそこに記録された溝内の隆起構造のような機械的にエンコードされたデバイス、及び上記のいずれかの適切な組み合わせが挙げられる。本明細書で使用される場合、コンピュータ可読ストレージ媒体は、電波、又は他の自由に伝搬する電磁波、導波管若しくは他の伝送媒体を通じて伝搬する電磁波（例えば、光ファイバ・ケーブルを通る光パルス）、又はワイヤを通って送られる電気信号などの、一時的信号自体として解釈されない。

本明細書で説明されるコンピュータ可読プログラム命令は、コンピュータ可読ストレージ媒体からそれぞれのコンピューティング／処理デバイスに、又は、例えばインターネット、ローカル・エリア・ネットワーク、広域ネットワーク、及び／又は無線ネットワークなどのネットワークを介して外部コンピュータ又は外部ストレージ・デバイスにダウンロードすることができる。ネットワークは、銅伝送ケーブル、光伝送ファイバ、無線伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、及び／又はエッジ・サーバを含むことができる。各コンピューティング／処理デバイスにおけるネットワーク・アダプタ・カード又はネットワーク・インターフェースは、ネットワークからコンピュータ可読プログラム命令を受け取り、コンピュータ可読プログラム命令を転送して、それぞれのコンピューティング／処理デバイス内のコンピュータ可読ストレージ媒体内に格納する。

本発明の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、ファームウェア命令、状態設定データ、又は、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋などのオブジェクト指向プログラミング言語、又は、「Ｃ」プログラミング言語若しくは類似のプログラミング言語などの通常の手続き型プログラミング言語を含む１つ又は複数のプログラミング言語の任意の組み合わせで記述することができる。コンピュータ可読プログラム命令は、完全にユーザのコンピュータ上で実行される場合もあり、一部がユーザのコンピュータ上で、独立型ソフトウェア・パッケージとして実行される場合もあり、一部がユーザのコンピュータ上で実行され、一部が遠隔コンピュータ上で実行される場合もあり、又は完全に遠隔コンピュータ若しくはサーバ上で実行される場合もある。最後のシナリオにおいて、遠隔コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）若しくは広域ネットワーク（ＷＡＮ）を含むいずれかのタイプのネットワークを通じてユーザのコンピュータに接続される場合もあり、又は外部コンピュータへの接続がなされる場合もある（例えば、インターネットサービスプロバイダを用いたインターネットを通じて）。幾つかの実施形態において、例えば、プログラム可能論理回路、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、又はプログラム可能論理アレイ（ＰＬＡ）を含む電子回路は、コンピュータ可読プログラム命令の状態情報を用いて、電子回路を個人化することによりコンピュータ可読プログラム命令を実行し、本発明の態様を実施することができる。

本発明の態様は、本発明の実施形態による方法、装置（システム）及びコンピュータ・プログラム製品のフローチャート図及び／又はブロック図を参照して説明される。フローチャート図及び／又はブロック図の各ブロック、並びにフローチャート図及び／又はブロック図内のブロックの組み合わせは、コンピュータ可読プログラム命令によって実装できることが理解されるであろう。

これらのコンピュータ可読プログラム命令を、汎用コンピュータ、専用コンピュータ、又は他のプログラム可能データ処理装置のプロセッサに与えてマシンを製造し、それにより、コンピュータ又は他のプログラム可能データ処理装置のプロセッサによって実行される命令が、フローチャート及び／又はブロック図の１つ又は複数のブロック内で指定された機能／動作を実施するための手段を作り出すようにすることができる。これらのコンピュータ可読プログラム命令を、コンピュータ、プログラム可能データ処理装置、及び／又は他のデバイスを特定の方式で機能させるように指示することができるコンピュータ可読媒体内に格納し、それにより、そのコンピュータ可読媒体内に格納された命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実施する命令を含む製品を製造するようにすることもできる。

コンピュータ可読プログラム命令を、コンピュータ、他のプログラム可能データ処理装置、又は他のデバイス上にロードして、一連の動作ステップをコンピュータ、他のプログラム可能データ処理装置、又は他のデバイス上で行わせてコンピュータ実施のプロセスを生成し、それにより、コンピュータ又は他のプログラム可能装置上で実行される命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実行するためのプロセスを提供するようにすることもできる。

図面内のフローチャート及びブロック図は、本発明の種々の実施形態による、システム、方法、及びコンピュータ・プログラム製品の可能な実装の、アーキテクチャ、機能及び動作を示す。この点に関して、フローチャート内の各ブロックは、指定された論理機能を実装するための１つ又は複数の実行可能命令を含む、モジュール、セグメント、又はコードの一部を表すことができる。幾つかの代替的な実装において、ブロック内に示される機能は、図に示される順序とは異なる順序で生じることがある。例えば、連続して示される２つのブロックは、関与する機能に応じて、実際には実質的に同時に実行されることもあり、又はこれらのブロックはときとして逆順で実行されることもある。ブロック図及び／又はフローチャート図の各ブロック、及びブロック図及び／又はフローチャート図内のブロックの組み合わせは、指定された機能又は動作を実行する、又は専用のハードウェアとコンピュータ命令との組み合わせを実行する、専用ハードウェア・ベースのシステムによって実装できることにも留意されたい。

本明細書で用いられる用語は、特定の実施形態を説明する目的のためのものにすぎず、本発明を限定することを意図したものではない。本明細書で用いられる場合、単数形「１つの（a）」、「１つの（an）」及び「その（the）」は、文脈が特に明示しない限り、複数形も同様に含むことを意図したものである。「含む（comprise）」及び／又は「含んでいる（comprising）」という用語は、本明細書で用いられる場合、記述された特徴、整数、ステップ、動作、要素、及び／又はコンポーネントの存在を指示するが、１つ又は複数の他の特徴、整数、ステップ、動作、要素、コンポーネント、及び／又はそれらの群の存在又は追加を排除するものではないこともさらに理解されるであろう。

以下の特許請求の範囲に存在する場合、「手段又はステップと機能との組合せ（ミーンズ又はステップ・プラス・ファンクション）」要素の対応する構造、材料、動作及び均等物は、明確に特許請求された他の請求要素と共に機能を実行するための任意の構造、材料、又は行為を含むことを意図したものである。本発明の説明は、例証及び説明のためだけに提示されたものであり、網羅的であること又は本発明を開示した形態に限定することを意図したものではない。当業者には、本発明の範囲から逸脱しない多くの修正物及び変形物が明らかとなるであろう。実施形態は、本発明の原理及び実際の用途を最もよく説明するため、及び、当業者が、企図した特定の用途に適するように種々の修正を有する種々の実施形態に関して本発明を理解することができるように、選択され記述された。

１００：方法
２００：グラフ
２０２、２０５、２０６、２０８、２１０、２１２、２１４：ノード
２１６、２１８、２２０、２２２、２２４、２２６、２２８：リンク
３００：ネットワーク
３０４、３０６、３０８：ソフトウェア・モジュール
３１０、３１２、３１４：通信チャネル

Claims (13)

1. 通信チャネルを介して互いに通信する複数のソフトウェア・モジュールを含むシステムにおけるボトルネックを検出するための方法であって、
   グラフを受信することであって、前記グラフのノードは前記ソフトウェア・モジュールの１つを表し、前記グラフのエッジはソフトウェア・モジュール間のデータ・フローを有する前記通信チャネルの１つを表す、前記グラフを受信することと、
   各ソフトウェア・モジュールについて、選択されたリソースについて、前記ソフトウェア・モジュールにより消費される前記リソースの量対利用可能なリソースの量の比を監視することと、
   各通信チャネルについて、前記通信チャネルの１つにより消費される帯域幅対前記通信チャネルの利用可能な帯域幅の比及び前記通信チャネルのアイドル時間の量を監視することと、
   アイドル・モードにあるソフトウェア・モジュールについて、生成される出力量が、前記アイドル・モードにあるソフトウェア・モジュールが必要とする前記出力量を下回るソース・ソフトウェア・モジュールを前記グラフから識別することと、
   前記識別したソース・ソフトウェア・モジュールのリソース消費を分析して、前記識別したソース・ソフトウェア・モジュールについてのリソースの不足量を識別することと、
   を含む、方法。
2. 前記ノードは受信する入力データの量対前記入力データから導かれる生成される出力データの量の予測される比を表す所定の係数に関連する、請求項１に記載の方法。
3. 前記監視したリソース量の比ならびに前記監視した帯域幅の比及び前記アイドル時間の量に基づいて、前記アイドル・モードにあるソフトウェア・モジュールを特定する、請求項１に記載の方法。
4. 前記ノードは、データ・ソース、データ処理システム、及びユーザ・インターフェースを含む群から選択される、請求項１に記載の方法。
5. 前記データ・ソースは、データベース、ファイル・システム、コンテンツ管理システム、又はストリーミング・データ・インターフェースである、請求項４に記載の方法。
6. 前記ソフトウェア・モジュールの少なくとも１つはマイクロ・サービスである、請求項１〜請求項５の１項に記載の方法。
7. 前記リソース消費を分析することは、ある期間にわたって前記リソースのサポート不足を追跡し、報告することを含む、請求項１〜請求項６の１項に記載の方法。
8. 前記リソース消費を分析することは、前記リソースのサポート不足を防止する勧告を決定することを含む、請求項１〜請求項７の１項に記載の方法。
9. 前記リソース消費を分析することは、前記ソフトウェア・モジュールを異なるコンピューティング・システムに移動することを含む、請求項１〜請求項８の１項に記載の方法。
10. 前記リソース消費を分析することは、前記システムが前記リソースの変化にどのように反応するかを予測することを含む、請求項１〜請求項９の１項に記載の方法。
11. 前記リソース消費を分析することは、前記同じコンピューティング・システム上の前記リソース不足をめぐって競合する別のソフトウェア・モジュールを追跡し、報告することを含む、請求項１〜請求項１０の１項に記載の方法。
12. 通信チャネルを介して互いに通信する複数のソフトウェア・モジュールを含むシステムにおけるボトルネックを検出するためのボトルネック識別システムであって、
    グラフを受信する受信ユニットであって、前記グラフのノードは前記ソフトウェア・モジュールの１つを表し、前記グラフのエッジはソフトウェア・モジュール間のデータ・フローを有する前記通信チャネルの１つを表す、受信ユニットと、
    各ソフトウェア・モジュールについて、選択されたリソースについて、前記ソフトウェア・モジュールにより消費される前記リソースの量対利用可能なリソースの量の比を監視するように適合され、かつ、各通信チャネルについて、前記通信チャネルの１つにより消費される帯域幅対前記通信チャネルの利用可能な帯域幅の比及び前記通信チャネルのアイドル時間の量を監視するようにも適合された監視ユニットと、
    アイドル・モードにあるソフトウェア・モジュールについて、生成される出力量が、前記アイドル・モードにあるソフトウェア・モジュールが必要とする前記出力量を下回るソース・ソフトウェア・モジュールを前記グラフから識別するように適合されたトラバース・モジュールと、
    前記識別したソース・ソフトウェア・モジュールのリソース消費を分析して、前記識別したソース・ソフトウェア・モジュールについてのリソースの不足量を識別するように適合された分析モジュールと、
    含む、ボトルネック識別システム。
13. 通信チャネルを介して互いに通信する複数のソフトウェア・モジュールを含むシステムにおけるボトルネックを検出するためのコンピュータ・プログラムであって、前記コンピュータ・プログラムは、コンピューティング・システムに、
    グラフを受信することであって、前記グラフのノードは前記ソフトウェア・モジュールの１つを表し、前記グラフのエッジはソフトウェア・モジュール間のデータ・フローを有する前記通信チャネルの１つを表す、前記グラフを受信することと、
    各ソフトウェア・モジュールについて、選択されたリソースについて、前記ソフトウェア・モジュールにより消費される前記リソースの量対利用可能なリソースの量の比を監視することと、
    各通信チャネルについて、前記通信チャネルの１つにより消費される帯域幅対前記通信チャネルの利用可能な帯域幅の比及び前記通信チャネルのアイドル時間の量を監視することと、
    アイドル・モードにあるソフトウェア・モジュールについて、生成される出力量が、前記アイドル・モードにあるソフトウェア・モジュールが必要とする前記出力量を下回るソース・ソフトウェア・モジュールを前記グラフから識別することと、
    前記識別したソース・ソフトウェア・モジュールのリソース消費を分析して、前記識別したソース・ソフトウェア・モジュールについてのリソースの不足量を識別することと、
    を実行させるためのコンピュータ・プログラム。

Images