JP6090327B2

JP6090327B2 - ボトルネック検出装置、方法及びプログラム

Info

Publication number: JP6090327B2
Application number: JP2014538237A
Authority: JP
Inventors: 堀川　隆; 隆堀川
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2012-09-25
Filing date: 2013-07-08
Publication date: 2017-03-08
Anticipated expiration: 2033-07-08
Also published as: WO2014050254A1; US20150227446A1; JPWO2014050254A1; US9652355B2

Description

本発明は、情報処理装置の性能のボトルネックを分析する技術に関し、特に高負荷動作時にボトルネックが形成されるプログラム部分とボトルネックが形成される原因を判定するための分析技術に関する。

情報処理装置の振舞い分析は、情報処理装置が所望の性能を発揮しない原因となる部分処理（以降、ボトルネック）を特定し、ボトルネックとなる原因を除去あるいは緩和することで性能の向上を図るという目的で行なわれることが多い。ここで、ボトルネックは、プログラムのある特定部分の処理に帰着できることが多いことから、振舞い分析の大きな目的は、ボトルネックとなっているプログラム部分を特定すること、といえる。

情報処理装置の振舞いを表す性能指標として多用されているのは、実行時間である。理由は、最も直接的にシステムの性能を反映する性能指標だからである。このため、実行時間を調べる測定ツールや、性能を分析するツールや手法が数多く考案されている。特許文献１には、イベント・ドリブン方式（厳密には、その一形態であるイベント・トレース方式）の測定ツールを用いたサーバ装置の振舞い分析について開示されている。図１のボトルネック検出システムの概略構成図を参照して特許文献１における分析方法を説明する。まず、測定対象であるプログラムの各部分（プログラム部品）ついて、実行の開始と終了に対応する位置にトレース対象イベントを出力する測定機能（アプリケーション・プローブ）を挿入する。この状態でプログラムを実行させてイベントの時系列データ（トレース・データ）を採取し、そのトレース・データを解析・集計することによって、測定対象となっているプログラムの各部分について、実行時間を求める。

イベント・ドリブン方式とは異なるサンプリング方式により、プログラムの各部分について実行時間を推定する方式の測定ツールもある。例としては、CPU（Central Processing Unit）内蔵の性能カウンタを用いてプログラムの振舞いを計測するツールであるoprofile（非特許文献１参照）がある。oprofileの測定原理は、性能カウンタに測定対象ハードウェア・イベントの種類と回数を指定しておくと、そのイベントが指定回数発生したときにオーバフロー割込み(NMI)が発生することを利用したものである。具体的には、オーバフロー割り込みが発生する度に、そのときのプログラム位置を記録する、という操作を行うことでオーバフロー割り込みが発生したプログラム位置の分布が求まるが、oprofileでは、このような測定を長時間行なって得られる分布を、大数の法則を根拠として、ハードウェア・イベントが発生するプログラム位置の分布とみなすわけである。

図２に、oprofileによる測定結果の一例として、CPUを駆動するクロックが１サイクル進む、というハードウェア・イベントを測定対象イベントとして指定することで得られた「プログラムの各部分の実行に要する時間」を示す。この図の各行がプログラムの各部分についての集計値である。各列は、左列より、イベント発生回数、その割合（全イベント発生回数の合計が100%）、プログラム名、プログラム内の関数名となっている。

なお、インテルのx86プロセッサの場合、CPUの性能カウンタに設定できる測定対象ハードウェア・イベントはプロセッサの種類毎に異なっているが、実行時間（クロックが１サイクル進むというイベント）、実行命令数（CPUが１命令の実行を終了するというイベント）、CPU内蔵キャッシュ・ミス、といったイベントはどの種類のプロセッサでも共通して測定できるようになっている。

どのプログラム部品がボトルネックになっているのかを判定する方法に関する従来技術としては、特許文献１に、負荷の低い状態におけるプログラム各部分の実行時間と、負荷の高い状態におけるプログラム各部分の実行時間を比較し、増加の著しいプログラム部分をボトルネックと判定する方法が示されている。

特開２００６−２２７９９９号公報

"OProfile"、［online］、インターネット、〈URL：http://oprofile.sourceforge.net〉

上記の従来技術では、ボトルネックとなっているプログラム部分は判明するが、その原因までは判明しないことが問題となる。原因が判明しない理由は、ボトルネックの分析において、時間に関する性能指標のみを使用していたためである。

本発明の目的は、ボトルネックとなっているプログラム部分を特定することに加え、そのプログラム部分がボトルネックになっている原因を特定する技術を提供することである。

本発明のボトルネック検出装置は、情報処理装置が実行した各部分処理について性能指標ごとに測定した性能指標値を記憶する記憶手段と、前記記憶された性能指標値に基づいて、前記各部分処理についての特徴ベクトルを作成する作成手段と、前記作成された特徴ベクトルに基づいて、前記情報処理装置の性能のボトルネックとなる前記部分処理と、前記ボトルネックとなる原因である性能指標とを判定する判定手段とを備えることを特徴とする。

本発明のボトルネック検出方法は、制御部と記憶部とを有するコンピュータにおいて実施される方法であって、前記制御部が、情報処理装置で実行された各部分処理について性能指標ごとに測定された性能指標値を前記記憶部に記憶する記憶ステップと、前記制御部が、前記記憶された性能指標値に基づいて、前記各部分処理についての特徴ベクトルを作成する作成ステップと、前記制御部が、前記作成された特徴ベクトルに基づいて、前記情報処理装置の性能のボトルネックとなる前記部分処理と、前記ボトルネックとなる原因である性能指標とを判定する判定ステップとを備えることを特徴とする。

本発明のプログラムは、コンピュータを、情報処理装置が実行した各部分処理について性能指標ごとに測定した性能指標値を記憶する記憶手段、前記記憶された性能指標値に基づいて、前記各部分処理についての特徴ベクトルを作成する作成手段、前記作成された特徴ベクトルに基づいて、前記情報処理装置の性能のボトルネックとなる前記部分処理と、前記ボトルネックとなる原因である性能指標とを判定する判定手段として機能させることを特徴とする。

本発明によれば、ボトルネックとなっているプログラム部分を特定することに加え、そのプログラム部分がボトルネックになっている原因を特定する技術を提供することができる。

従来技術におけるボトルネック検出システムの概略構成を示すブロック図である。測定手段の一例であるoprofileの出力例を示す図である。本発明の一実施形態におけるシステムの構成を示すブロック図である。測定結果格納手段に格納する情報の内容の一例を示す図である。測定結果格納手段に格納する情報の形式の一例を示す図である。正規化手段により正規化された測定結果の内容の一例を示す図である。関数毎に作成する特徴ベクトルの内容の一例を示す図である。

以下に、本発明の実施の形態について図面を参照して詳細に説明する。
図３を参照して、本実施形態におけるボトルネック検出のためのシステムの構成を説明する。このシステムは、プログラム制御により動作する測定対象サーバ３１と、負荷発生手段３２と、測定結果格納手段３３と、解析手段３４と、制御手段３５とを含む。測定対象サーバ３１で動作するソフトウェアは、トランザクション処理プログラム３１１、OS kernel３１２、及び測定手段３１３を含む。測定対象サーバ３１は、サーバ装置などの情報処理装置によって構成される。また、解析手段３４は、正規化手段３４１と、処理負荷保持手段３４２と、判定手段３４３と、判定結果表示手段３４４とを含む。これらの手段の動作の概要について以下に説明する。

負荷発生手段３２は、制御手段３５から負荷発生開始が指示されると、制御手段３５から指定された負荷量に従って測定対象サーバ３１にトランザクションを送り、測定対象サーバ３１によって測定時間内に処理されたトランザクション数を計測する。制御手段３５から測定終了が指示されると、負荷発生手段３２は、指定された負荷量と測定時間（測定開始から終了までの時間）と計測したトランザクション数とを測定結果格納手段３３に格納するとともに、測定操作を終了する。

測定対象サーバ３１では、負荷発生手段３２から送られるトランザクションがOS kernel３１２で受信され、トランザクション処理プログラム３１１に送られて処理される。処理結果は、OS kernel３１２を介してトランザクションの要求元に返される。測定手段３１３は、制御手段３５から測定開始を指示されると、制御手段３５から指示された性能指標の測定を行なう。制御手段３５から測定終了が指示されると、測定手段３１３は測定した結果を測定結果格納手段３３に格納するとともに、測定操作を終了する。

解析手段３４は、制御手段３５からの指示に基づき、測定結果格納手段３３に格納された測定結果を処理してボトルネック箇所と原因を判定し、その結果を判定結果表示手段３４４により表示する。

なお、図３に示したシステムは、図示しないが、一般的なコンピュータが備えるように、CPUなどの制御部、メモリ及びHDD（Hard Disc Drive）などの記憶部、並びに通信モジュールなどのインタフェースを備える。上記の各手段は、例えば、CPUがHDDに記憶されたプログラムをメモリに展開して実行することによって実現される。すなわち、上記の各手段は、ハードウェアとソフトウェアの協働により実現される。

以下、上記動作について具体例を用いて詳細に説明する。
測定手段３１３は、oprofileを使用して性能の測定を行う。oprofileで測定可能な性能指標はプロセッサによって異なるが、本実施例では、実行時間、実行命令数、キャッシュ・ミス回数、バス・ロック操作回数を含んでいるものとする。実行時間はプログラムの実行に要した時間である。実行命令数はプログラムの実行に要した命令数である。キャッシュ・ミス回数はプログラム実行に伴って発生したキャッシュ・ミスの回数である。バス・ロック操作回数は排他制御操作に伴って実行されたバス・ロック操作の回数である。

これらの測定結果は、従来技術で説明した測定原理に従って、プログラム内の関数（部分処理）毎に集計される。oprofileでは、１回の測定で得られる性能指標は１種類であるため、複数種類の性能指標について測定結果を得る場合は、各性能指標について同じ負荷量を指定した測定を複数回実施する。

本実施形態では、制御手段３５が制御して行なう測定は、負荷量が低負荷（以降、ｌと表記）と高負荷（以降、hと表記）の２種類であり、測定手段３１３により測定する性能指標が実行時間（以降、ｔと表記）、実行命令数（以降、iと表記）、キャッシュ・ミス回数（以降、cと表記）、バス・ロック操作回数（以降、kと表記）の４種類とする。すなわち、測定を行なう回数は、負荷量と性能指標の組み合わせである８回である。簡単のため、これらの測定は同じ時間（以降、Tと表記）実施するものとする。

図４は、例えば、負荷量がl、性能指標名がt、測定時間がTという条件で実施した性能の測定で得られる結果を示している。ここでは、測定結果は、負荷発生手段が計測する測定時間（T）内に測定対象サーバ３１が実行したトランザクションの数（以降、X_ltと表記）と、oprofileが計測する関数毎（以降、Ｆ1〜ｎと表記）のイベント発生回数（Ｎ１_lt〜Ｎｎ_ltと表記）を含んでいる。ここで、ＦとＮに添えられた1〜ｎは関数の番号、Ｎに添えられたltは測定条件を表現する添え字である。

本実施形態における測定結果は、profileによる測定結果である関数名とイベント発生回数の表（図４の測定結果２）の各行に、実行条件である負荷量、性能指標名、測定時間と、負荷発生手段３２による計測結果である実行トランザクション数の列を付け加えた表（図５）として、測定結果格納手段３３に格納される。

ここで重要な点は、表の列に性能指標名を加えることで、負荷量を同じとする実行状況に関して複数種類の性能指標についての測定結果を取り出すことができるようにした点である。なお、このように複数種類の性能指標についての測定結果を取り出すことができるように測定結果を格納する方法は、図５に示したような表を格納する方法に限定されない。性能の測定結果を格納する方法は、負荷量を同じとする実行状況に関して複数種類の性能指標についての測定結果を取り出すことができるという特徴を有する限り、それらは本発明に含まれる。

制御手段３５が制御して行なう８回の測定が終了すると、制御手段３５は解析手段３４を起動する。解析手段３４が起動されると、まず、正規化手段３４１により、測定結果格納手段３３に格納されている表の各行に対して、１トランザクション当たりのイベント発生回数（＝イベント発生回数／実行トランザクション回数）とスループット（＝実行トランザクション回数／測定時間）を求め、これらを新たな列として表に付け加える。この処理により作成される表の一例を図６に示す。

次に、正規化手段３４１は、図６の表に出現する関数（部分処理）すべてについて、図７に示す特徴ベクトルを作成する。ここで、特徴ベクトルの各要素は、各性能指標について、（高負荷時の１トランザクション当たりのイベント発生回数）／（低負荷時の１トランザクション当たりのイベント発生回数）、である。本実施形態では比を特徴ベクトルの要素としたが、比の代わりに差を使う実施形態も本発明から容易に考案可能な技術内容であり、本発明に含まれる。すなわち、特徴ベクトルは、性能指標ごとに算出された要素を含んでおり、各要素は、低負荷をかけて測定した性能指標値と高負荷をかけて測定した性能指標値との間の関係に基づいている。

各関数についての特徴ベクトルは、判定手段３４３に入力される。判定手段３４３は、ボトルネックとなっている関数（部分処理）およびボトルネックとなる原因を判定する。具体的には、判定手段３４３は、まず、関数を実行時間の比が大きい順に並び替えた結果において上位に位置する関数をボトルネック部分として抽出する。次に、判定手段３４３は、ボトルネック部分として抽出された関数の特徴ベクトルの各要素（すなわち、実行命令数、キャッシュ・ミス回数、バス・ロック操作回数）の各比を調べ、最も大きな値となっている要素をボトルネックの原因と判定する。

具体的には、比が最も大きな値となった要素が、1)実行命令数の場合は、負荷の増加により実行すべき命令数（≒処理の量）が増加したことがボトルネックの原因と判定される。2)キャッシュ・ミス回数の比が最も大きな値である場合、負荷の増加によりキャッシュ・ミスが増加し、その結果、平均メモリ・アクセス時間が増大したことがボトルネックの原因と判定される。3)バス・ロック操作回数の比が最も大きな値である場合、負荷の増加により排他制御の操作回数が増加したことがボトルネックの原因と判定される。すなわち、ボトルネックの原因である性能指標は、性能指標ごとに算出された特徴ベクトルの要素に基づいて判定される。

ソフトウェア動作と対応させて考えてみると、この判定結果は当該関数内に、1)の場合は例えば、負荷量に応じて実行回数が決まるループ、2)の場合は、負荷量に応じてアクセスするデータ量が決まる配列などのデータ、3)の場合は、負荷量の増加につれて競合が激しくなる排他制御、が存在していることを提示していると解釈することができる。すなわち、この判定操作によって、ボトルネック部分（関数）と、ボトルネックの原因を判定できたことになる。

なお、サンプリング方式により各関数内でのイベント発生回数を推定する測定ツール（oprofileなど）では、イベント発生回数が小さい値の場合は誤差が大きくなるため、高負荷時と低負荷時のイベント発生回数比に含まれる誤差も大きくなる可能性がある。イベント発生回数が小さい性能指標、例えば、図２の結果において発生割合が予め定めた値より小さい値となっている性能指標は、処理性能に与える影響も小さい。そのため、この値（イベント発生回数、又はイベント発生割合）が小さい要素については判定対象から除外する、というフィルタ操作を判定操作に含めることも考えられる。このようなフィルタ操作を行う判定手段３４３も本発明から容易に考案可能な技術内容であり、本発明に含まれる。

判定手段３４３による判定結果（すなわち、ボトルネックとなる部分及びボトルネックの原因）は、判定結果表示手段３４４によって人が理解できる形式で表示される。なお、判定結果は、表示によって出力されることに限定されず、コンピュータが認識可能な形式で外部装置に出力されることとしても良い。

この出願は、２０１２年９月２５日に出願された日本出願特願２０１２−２１１４０３を基礎とする優先権を主張し、その開示の全てをここに取り込む。

以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

上述した実施形態の一部または全部は、以下の付記のようにも記載され得るが、本発明を以下のように限定するものではない。

（付記１）情報処理装置が実行した各部分処理について性能指標ごとに測定した性能指標値を記憶する記憶手段と、
前記記憶された性能指標値に基づいて、前記各部分処理についての特徴ベクトルを作成する作成手段と、
前記作成された特徴ベクトルに基づいて、前記情報処理装置の性能のボトルネックとなる前記部分処理と、前記ボトルネックとなる原因である性能指標とを判定する判定手段と
を備えることを特徴とするボトルネック検出装置。

（付記２）前記記憶された性能指標値は、前記情報処理装置に低負荷をかけたときと高負荷をかけたときのそれぞれについて測定した性能指標値を含み、
前記作成された特徴ベクトルは、前記低負荷のときの性能指標値と前記高負荷のときの性能指標値との間の関係にさらに基づいていることを特徴とする付記１に記載のボトルネック検出装置。

（付記３）前記作成された特徴ベクトルは、性能指標ごとに算出された要素を含み、
前記ボトルネックとなる原因である性能指標は、前記性能指標ごとに算出された要素に基づいて判定されることを特徴とする付記１又は２に記載のボトルネック検出装置。

（付記４）前記判定されたボトルネックとなる部分処理とボトルネックとなる原因である性能指標とを出力する出力手段を備えることを特徴とする付記１から３のいずれか１つに記載のボトルネック検出装置。

（付記５）制御部と記憶部とを有するコンピュータにおいて実施される方法であって、
前記制御部が、情報処理装置で実行された各部分処理について性能指標ごとに測定された性能指標値を前記記憶部に記憶する記憶ステップと、
前記制御部が、前記記憶された性能指標値に基づいて、前記各部分処理についての特徴ベクトルを作成する作成ステップと、
前記制御部が、前記作成された特徴ベクトルに基づいて、前記情報処理装置の性能のボトルネックとなる前記部分処理と、前記ボトルネックとなる原因である性能指標とを判定する判定ステップと
を備えることを特徴とするボトルネック検出方法。

（付記６）コンピュータを、
情報処理装置が実行した各部分処理について性能指標ごとに測定した性能指標値を記憶する記憶手段、
前記記憶された性能指標値に基づいて、前記各部分処理についての特徴ベクトルを作成する作成手段、
前記作成された特徴ベクトルに基づいて、前記情報処理装置の性能のボトルネックとなる前記部分処理と、前記ボトルネックとなる原因である性能指標とを判定する判定手段
として機能させるためのプログラム。

本発明の活用例として、情報システム構築において、負荷テストを行なう際に発生する性能問題、特に、複数のトランザクションの並行処理に起因する性能ボトルネックについて原因となっている場所と原因を効率的に発見するためのプログラムといった用途に適用できる。

３１測定対象サーバ、３２負荷発生手段、３３測定結果格納手段、３４解析手段、３５制御手段

Claims

情報処理装置が実行した各部分処理について性能指標ごとに測定した性能指標値を記憶する記憶手段と、
前記記憶された性能指標値に基づいて、前記各部分処理についての特徴ベクトルを作成する作成手段と、
前記作成された特徴ベクトルに基づいて、前記情報処理装置の性能のボトルネックとなる前記部分処理と、前記ボトルネックとなる原因である性能指標とを判定する判定手段と
を備えることを特徴とするボトルネック検出装置。
前記記憶された性能指標値は、前記情報処理装置に低負荷をかけたときと高負荷をかけたときのそれぞれについて測定した性能指標値を含み、
前記作成された特徴ベクトルは、前記低負荷のときの性能指標値と前記高負荷のときの性能指標値との間の関係にさらに基づいていることを特徴とする請求項１に記載のボトルネック検出装置。
前記作成された特徴ベクトルは、性能指標ごとに算出された要素を含み、
前記ボトルネックとなる原因である性能指標は、前記性能指標ごとに算出された要素に基づいて判定されることを特徴とする請求項１又は２に記載のボトルネック検出装置。
前記判定されたボトルネックとなる部分処理とボトルネックとなる原因である性能指標とを出力する出力手段を備えることを特徴とする請求項１から３のいずれか１項に記載のボトルネック検出装置。
制御部と記憶部とを有するコンピュータにおいて実施される方法であって、
前記制御部が、情報処理装置で実行された各部分処理について性能指標ごとに測定された性能指標値を前記記憶部に記憶する記憶ステップと、
前記制御部が、前記記憶された性能指標値に基づいて、前記各部分処理についての特徴ベクトルを作成する作成ステップと、
前記制御部が、前記作成された特徴ベクトルに基づいて、前記情報処理装置の性能のボトルネックとなる前記部分処理と、前記ボトルネックとなる原因である性能指標とを判定する判定ステップと
を備えることを特徴とするボトルネック検出方法。
コンピュータを、
情報処理装置が実行した各部分処理について性能指標ごとに測定した性能指標値を記憶する記憶手段、
前記記憶された性能指標値に基づいて、前記各部分処理についての特徴ベクトルを作成する作成手段、
前記作成された特徴ベクトルに基づいて、前記情報処理装置の性能のボトルネックとなる前記部分処理と、前記ボトルネックとなる原因である性能指標とを判定する判定手段
として機能させるためのプログラム。