(57)【要約】      （修正有）【課題】負荷が大きく上がったリソースを特定できる情報処理装置を提供する。【解決手段】情報処理装置５００のテーブル記憶部５１０は、メソッドと、当該メソッドがアクセスするリソースと、が対応付けられたテーブルを記憶する。取得部５０１は、計算機システムにより実行されるプロセスに含まれる複数のスレッド毎に対応する複数のスタックトレースを取得する。リソース特定部５０２は、取得した複数のスタックトレース内にそれぞれ記述されたメソッドと、テーブルとに基づいて、プロセスの実行によりアクセスされるリソース毎の比率に応じて、所定の条件を満たすリソースを特定する。【選択図】図１１
2017068299.tif 000002
【特許請求の範囲】
【請求項１】
メソッドと、当該メソッドがアクセスするリソースと、が対応付けられたテーブルを記憶するテーブル記憶部と、
計算機システムにより実行されるプロセスに含まれる複数のスレッド毎に対応する複数のスタックトレースを取得する取得部と、
取得した複数の前記スタックトレース内にそれぞれ記述されたメソッドと、前記テーブルとに基づいて、プロセスの実行によりアクセスされるリソース毎の比率に応じて、所定の条件を満たすリソースを特定するリソース特定部と、
を備えた情報処理装置。
【請求項２】
請求項１に記載の情報処理装置であって、
前記取得部は、複数のスレッド毎に対応する複数のスタックトレースを含むスレッドダンプを取得し、
前記リソース特定部は、取得した前記スレッドダンプに含まれる複数の前記スタックトレース内のそれぞれ一部に記述されたメソッドと、前記テーブルとに基づいて、所定の条件を満たすリソースを特定する、
情報処理装置。
【請求項３】
請求項２に記載の情報処理装置であって、
前記リソース特定部は、前記スレッッドダンプに含まれる複数の前記スタックトレースのそれぞれ先頭行に記述されたメソッドと、前記テーブルとに基づいて、所定の条件を満たすリソースを特定する、
情報処理装置。
【請求項４】
請求項１乃至３のいずれかに記載の情報処理装置であって、
前記リソース特定部は、過去に取得された複数の前記スタックトレース毎にそれぞれ対応するリソース間の比率を表す過去リソース間比率と、最も新しく取得された複数の前記スタックトレース毎にそれぞれ対応するリソース間の比率を表す最新リソース間比率と、を算出し、前記過去リソース間比率と前記リソース間比率とを比較して、比率の増加したリソースを特定する、
情報処理装置。
【請求項５】
請求項４に記載の情報処理装置であって、
前記リソース特定部は、前記過去リソース間比率として、過去の所定期間に取得された複数の前記スタックトレース毎にそれぞれ対応するリソース間の比率の平均値を算出し、当該過去リソース間比率に対して、前記最新リソース間比率のうち比率が増加したリソースを特定する、
情報処理装置。
【請求項６】
請求項１乃至５のいずれかに記載の情報処理装置であって、
プロセス上で動作するアプリケーションのメソッドのリストを記憶するメソッドリスト記憶部と、
取得した複数の前記スタックトレースと前記メソッドリストとに基づいて、実行されたアプリケーションのメソッドの回数を当該メソッド毎に算出し、当該メソッドの回数に応じて所定の条件を満たすメソッドを特定するメソッド特定手段と、
を備えた情報処理装置。
【請求項７】
請求項６に記載の情報処理装置であって、
前記メソッド特定手段は、実行されたアプリケーションのメソッドの回数として、取得した複数の前記スタックトレース毎にスタックが最も深いアプリケーションのメソッドの回数を当該メソッド毎に算出する、
情報処理装置。
【請求項８】
請求項６又は７に記載の情報処理装置であって、
前記メソッド特定手段は、メソッド毎のメソッド回数が増加しているメソッドを特定する、
情報処理装置。
【請求項９】
情報処理装置に、
計算機システムにより実行されるプロセスに含まれる複数のスレッド毎に対応する複数のスタックトレースを取得する取得部と、
メソッドと当該メソッドがアクセスするリソースとが対応付けられたテーブルと、取得した複数の前記スタックトレース内にそれぞれ記述されたメソッドと、に基づいて、プロセスの実行によりアクセスされるリソース毎の比率に応じて、所定の条件を満たすリソースを特定するリソース特定部と、
を実現させるためのプログラム。
【請求項１０】
計算機システムにより実行されるプロセスに含まれる複数のスレッド毎に対応する複数のスタックトレースを取得し、
メソッドと当該メソッドがアクセスするリソースとが対応付けられたテーブルと、取得した複数の前記スタックトレース内にそれぞれ記述されたメソッドと、に基づいて、プロセスの実行によりアクセスされるリソース毎の比率に応じて、所定の条件を満たすリソースを特定する、
リソース特定方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置にかかり、特に、計算機システムのリソースを特定する情報処理装置に関する。
【背景技術】
【０００２】
計算機システムの仮想環境は、仮想化の方法やスペックにもよるが、実機環境と比較して性能面で劣る、という課題がある。例えば、fsync()によるディスク書き込み処理は、かかる処理が完了するまで他のディスク書き込みを行うことができないため、仮想環境上で頻発すると、実機環境と比較してディスク書き込み待ち時間が長くなってしまうおそれがある。
【０００３】
ここで、仮想環境上で動作しているアプリケーションサーバにおいてfsync()によるディスク書き込みが行われていても、OS（Operating System）のコマンドによるディスクIO（Input/Output）の負荷監視を行っても、負荷が上がったことを検出できない。もし、仮想環境上で過剰にfsync()が行われると、ディスクIO待ちを引き起こす可能性があることを理解していれば、アプリケーションの実装を点検するなどの対応により、事前にディスクIO待ち検出できる可能性があるが、上記のことを理解していない場合は難しい。
【０００４】
つまり、対象システムの仕様の理解度が低いと、性能劣化の要因を性能劣化発生前に検出することができず、性能劣化が顕在化してしまう。また、これまで対象システムで障害が発生した場合、その障害を解析して対処する必要があったが、システムの仕様の理解度が低いために解析に必要な情報が取得できていないことで、再現待ちになることが多々あった。さらに、障害の内容によっては、運用者の知識では情報が取得できない場合もあり、そのシステムの仕様を理解している技術者に障害の解析を依頼する必要があるため、解決まで長期化することがあった。
【０００５】
一方で、対象システムに対する仕様の理解度が低い者でも用いることができる一般的な手法として、計算機システムにおいて性能劣化が発生した際に、特定のリソース（例えば、ディスクIO：ネットワークIO：メモリコピー：キー入力など）に対して、OSのコマンドを使って負荷状況を調査する方法がある（例えば、特許文献１参照）。これにより、特定のリソースにアクセスする処理が性能面で異常原因となっていないかを確認することができる。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１１−１９８２６２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、上述した方法では、必ずしも性能劣化のボトルネックを特定できるとは限らない。例えば、メモリ上にあるファイルの内容をストレージデバイス上のものと同期するUNIX系OSのシステムコールとしてfsync()が存在するが、同期のために時間がかかり、その間は他からのディスクアクセスができず、ディスク書き込み待ちが発生するという弊害がある。また、Linux OSのリソースの負荷状況を計測するsarコマンドは、ディスク書き込み待ち時間を表すiostatを計測する手段であるが、fsync()による同期の時間はiostatの数値に反映されず、この場合はボトルネックの特定には不適切な手段となってしまう。そして、そもそもOSのコマンドではリソースにアクセスする処理を特定することができない、という問題がある。
【０００８】
また、スレッドダンプを解析することで、原因となる処理を特定することも一つの手段である。しかしながら、かかる方法を用いる場合には、スレッドダンプ全体を解析する必要があり、対象システムに対する仕様の理解度が高いことが求められてしまう。このため、かかる課題を解決するためには、対象システムに対する運用者の仕様の理解度が低くても、OSのコマンドを使用せずに負荷が大きく上がったリソースと、その原因となっている可能性のある処理を特定できる装置の開発が求められる。
【０００９】
そして、上述した状況は、計算機システムの仮想環境だけでなく、オンプレミスやクラウドに設置したサーバを運用する分野において、仕様を深く理解していなくても、負荷の大きく上がったリソース、その原因となっている可能性のある処理を監視して特定したい、という要望がある。
【００１０】
このため、本発明の目的は、上述した課題である、計算機システムに対する仕様の理解が低いと、負荷が大きく上がったリソースを特定することができない、という課題を解決することができる情報処理装置を提供することにある。
【課題を解決するための手段】
【００１１】
本発明の一形態である情報処理装置は、
メソッドと、当該メソッドがアクセスするリソースと、が対応付けられたテーブルを記憶するテーブル記憶部と、
計算機システムにより実行されるプロセスに含まれる複数のスレッド毎に対応する複数のスタックトレースを取得する取得部と、
取得した複数の前記スタックトレース内にそれぞれ記述されたメソッドと、前記テーブルとに基づいて、プロセスの実行によりアクセスされるリソース毎の比率に応じて、所定の条件を満たすリソースを特定するリソース特定部と、
を備えた、
という構成をとる。
【００１２】
また、本発明の一形態であるプログラムは、
情報処理装置に、
計算機システムにより実行されるプロセスに含まれる複数のスレッド毎に対応する複数のスタックトレースを取得する取得部と、
メソッドと当該メソッドがアクセスするリソースとが対応付けられたテーブルと、取得した複数の前記スタックトレース内にそれぞれ記述されたメソッドと、に基づいて、プロセスの実行によりアクセスされるリソース毎の比率に応じて、所定の条件を満たすリソースを特定するリソース特定部と、
を実現させる、
という構成をとる。
【００１３】
また、本発明の一形態であるリソース特定方法は、
計算機システムにより実行されるプロセスに含まれる複数のスレッド毎に対応する複数のスタックトレースを取得し、
メソッドと当該メソッドがアクセスするリソースとが対応付けられたテーブルと、取得した複数の前記スタックトレース内にそれぞれ記述されたメソッドと、に基づいて、プロセスの実行によりアクセスされるリソース毎の比率に応じて、所定の条件を満たすリソースを特定する、
という構成をとる。
【発明の効果】
【００１４】
本発明は、以上のように構成することにより、計算機システムに対する仕様の理解が低い場合であっても、負荷が大きく上がったリソースを特定することができる。
【図面の簡単な説明】
【００１５】
【図１】本発明の第１の実施形態における情報処理システムの構成を示すブロック図である。
【図２】図１に開示した各記憶部の構成を示すブロック図である。
【図３】図１に開示した各記憶部の構成を示すブロック図である。
【図４】図１に開示した高負荷リソース特定装置にてリソース間スタックトレース比率を算出する様子を示す図である。
【図５】図１に開示した高負荷リソース特定装置にてリソース間スタックトレース比率を算出する様子を示す図である。
【図６】スレッドバンプの一例を示す図である。
【図７】図１に開示した高負荷リソース特定装置の動作を示す図である。
【図８】本発明の第２の実施形態における情報処理システムの構成を示すブロック図である。
【図９】図８に開示した各記憶部の構成を示すブロック図である。
【図１０】図８に開示した高負荷リソース特定装置の動作を示す図である。
【図１１】本発明の付記１における情報処理装置の構成を示すブロック図である。
【発明を実施するための形態】
【００１６】
＜実施形態１＞
本発明の第１の実施形態を、図１乃至図７を参照して説明する。図１乃至図３は、実施形態１における情報処理システムの構成を説明するための図である。図４乃至図７は、高負荷リソース特定装置の動作を説明するための図である。
【００１７】
［構成］
本実施形態における情報処理システムは、図１に示すように、それぞれ演算装置や記憶装置を備えた、計算機システム１と、高負荷リソース特定装置２と、を備える。
【００１８】
計算機システム１は、装備された演算装置でプロセス１００を実行する。このとき、計算機システム１は、ディスクＩＯ、ネットワークＩＯ、メモリコピー、キー入力、などのリソースを用いた処理を行い、プロセス１００の実行を行う。なお、本発明におけるリソースとは、上述したものに限定されず、他のハードウェアやソフトウェアによるいかなるリソースであってもよい。
【００１９】
プロセス１００は、複数のスレッドで構成され、スレッドダンプ１０１を一定期間ごとに取得して記録する。スレッドダンプ１０１は、すべてのスレッドにそれぞれ対応するスタックトレースの集合である。つまり、プロセス１００を構成するすべてのスレッドに対して、スレッドダンプ１０１は１つであり、時間毎のスレッドダンプ１０１が記録される。なお、上記スタックトレースとは、スレッドごとにプログラムの実行過程を記録したスタックを指し、スレッド１つに対してスタックトレースは１つである。
【００２０】
そして、本実施形態では、高負荷リソース特定装置２が、上述した計算機システム１からスレッドダンプ１０１を取得して、当該スレッドダンプ１０１に含まれる各スタックトレースの処理内容を監視する。これにより、負荷が大きく上がったリソースと、その原因となっている可能性のあるアプリケーションのメソッドと、を特定することを行うものである。
【００２１】
なお、高負荷リソース特定装置２は、一定期間ごとに以降の動作を繰り返す。そして、以下で説明する「前回」という表現は、この一定期間ごとに行う繰り返しの前回分を示すこととする。
【００２２】
次に、高負荷リソース特定装置２の構成について、図１乃至図３を参照して説明する。高負荷リソース特定装置２は、演算装置にプログラムが組み込まれることで構築された、取得部１１０、分類部１２０、リソース間スタックトレース比率算出部１５０、高負荷リソース特定部１７０、高負荷リソース原因メソッド特定部１９０、を備える。
【００２３】
また、高負荷リソース特定装置２は、記憶装置に、分類用テーブル１３１を記憶する分類用テーブル記憶部１３０、分類後のスタックトレース１４１と前回分分類後のスタックトレース１４２を記憶する分類後のスタックトレース記憶部１４０、リソース間のスタックトレース比率１６１と過去のリソース間のスタックトレース比率１６２を記憶する比率記憶部１６０、高負荷リソース特定用閾値１８１を記憶する閾値記憶部１８０、アプリケーションのメソッドのリスト２０１を記憶するアプリケーションのメソッドのリスト記憶部２００、アプリケーションのメソッド数２１１と過去のアプリケーションのメソッド数２１２と過去のアプリケーションのメソッド数平均２１３を記憶するアプリケーションのメソッド数記憶部２１０、ログ記憶部２２０を有する。
【００２４】
上記取得部１１０は、計算機システム１のプロセス１００から、スレッドダンプ１０１を取得する。なお、取得部１１０は、一定期間毎にスレッドダンプ１０１を取得する。
【００２５】
上記分類部１２０は、まず、取得部１１０が取得したスレッドダンプ１０１に含まれる各スタックトレースの先頭行のメソッドを取り出す。そして、分類用テーブル記憶部１３０に記憶されている分類用テーブル１３１を参照して、取り出したメソッドを、当該メソッドによりアクセスするリソース（例えば、ディスクＩＯ：ネットワークＩＯ：メモリコピー：キー入力）ごとに分類し、分類後のスタックトレース１４１として記録する。このとき、既に記憶されていた分類後のスタックトレース１４１を前回分分類後のスタックトレース１４２として退避する。
【００２６】
なお、上記分類用テーブル１３１（テーブル）は、メソッドと、当該メソッドがアクセスするリソースと、が対応付けられたテーブルである。
【００２７】
上記リソース間スタックトレース比率算出部１５０は、まず、分類後のスタックトレース１４１を集計して、使用しているリソースごとに比率を算出し、リソース間スタックトレース比率１６１として比率記憶部１６０に記録する。このとき、既に前回分のリソース間スタックトレース比率１６１が記憶されている場合には、既に記憶されている過去のリソース間スタックトレース比率１６２の中で最も新しいものとして退避する。これにより、過去のリソース間スタックトレース比率１６２は、リソース間スタックトレース比率１６１の過去の十分な回数分を記録したものとなる。
【００２８】
そして、リソース間スタックトレース比率算出部１５０は、過去のリソース間スタックトレース比率１６２の平均を算出して、リソース間スタックトレース比率平均１６３として記録する。なお、リソース間スタックトレース比率算出部１５０による具体的な処理については、動作説明時に詳しく説明する。
【００２９】
上記高負荷リソース特定部１７０は、現在における特定のリソースの負荷が、前回のスレッドダンプ１０１の取得時やリソース間スタックトレース比率平均１６３を算出したときといった過去の状況と比較して、大きく上がったかどうかを判定し、負荷が大きく上がったリソースを特定する。そして、高負荷リソース特定部１７０は、特定したリソースを、ログ記憶部２２０に出力して記憶する。なお、負荷が大きく上がったリソースの特定は、以下の考え方に基づき、以下の方法によって行う。
【００３０】
特定のリソースの負荷が上がり、リソースの空き待ちが発生することで、なぜそのリソースを使用するスタックトレースの先頭行のメソッドとして出力されるスレッドが増えるのか（なぜ、スタックトレースの先頭行のメソッドだけ参照しても負荷の上がったリソースを特定できるのか）、図４を用いて説明する。図中メソッドA,B,Cはそれぞれ、リソースa,b,cを使用するスタックトレースの先頭行のメソッドである。また、ユーザスレッド1〜12ではアプリケーションに関する処理が行われ、リソースa,b,c低負荷時のメソッドA,B,Cは、いずれも処理遅延が発生せずに任意のタイミングにおいてスタックトレースの先頭行に均等に現れる。このため、各メソッドの比率は、任意のタイミングにおいて均等に算出される（図中の今回分、前回採取分、前々回採取分において、メソッドA：メソッドB：メソッドC = 33% ：33% ：33%)。
【００３１】
一方で、図５に示すように、リソースaのみが高負荷時には、リソースaの待ち時間が発生することで、各ユーザスレッドでメソッドAの処理時間が長くなり、任意のタイミングにおいてスタックトレースの先頭行に出力される頻度が上がる。すると、メソッドAを実行しているスレッドの比率も高くなる（図中の今回分、前回採取分、前々回採取分において、メソッドA：メソッドB：メソッドC = 50% ：25% ：25%）。
【００３２】
そして、リソースa,b,c低負荷時とリソースaのみ高負荷時の比率を比較すると、メソッドAが17%増加しており（33%→50%）、リソースaの待ちの発生がスタックトレースの先頭行のメソッドのスレッド間の比率に反映されていると言える。ただし、この考え方の前提として、比較対象となるリソースa,b,c低負荷時のスタックトレースの先頭行のメソッドのスレッド間の比率は、十分に収束している必要があり、十分な回数の平均値であることが望ましい。
【００３３】
なお、リソースが高負荷であると判定する基準は、今回分のリソース間スタックトレース比率から前回分までのリソース間スタックトレース比率平均を引いた値が、閾値記憶部１８０に記憶された予め設定された高負荷リソース判定用閾値１８１よりも大きい場合としてもよい。
【００３４】
こうすることで、本発明では各スタックトレースの先頭行のメソッドのみ参照してリソース間の比率を算出するだけで、負荷の大きく上がったリソースを特定することができる。このように、上記分類部１２０、リソース間スタックトレース比率算出部１５０、高負荷リソース特定部１７０は、協働して、負荷が大きく上がったリソースを特定するリソース特定部として作動する。
【００３５】
上記高負荷リソース原因メソッド特定部１９０は、リソースの負荷が大きく上がった原因となっている可能性のあるアプリケーションのメソッドを特定する。具体的に、高負荷リソース原因メソッド特定部１９０は、まず、アプリケーションのメソッドのリストを参照して、スレッドダンプ１０１上のスタックトレースごとの最も深い位置（先頭行に近い位置）にあるアプリケーションのメソッドについて、メソッドごとに実行された回数を集計する。
【００３６】
なお、アプリケーションのメソッドのリスト記憶部２００は、アプリケーションのメソッドのリスト２０１を記録する記憶領域である。アプリケーションのメソッドのリスト２０１、プロセス１００上で動作しているアプリケーションのメソッドと、その引数の数・型の一覧である。アプリケーションのメソッドのリスト２０１は事前に記憶されているものとする。
【００３７】
そして、高負荷リソース原因メソッド特定部１９０は、上述したように算出したメソッド毎に実行された回数を、アプリケーションのメソッド数２１１として、アプリケーションメソッド数記憶部２１０に記憶する。この時、既に記憶されていたアプリケーションのメソッド数２１１は、過去のアプリケーションのメソッド数２１２の中で最も新しいものとして退避する。過去のアプリケーションのメソッド数２１２は、アプリケーションのメソッド数２１１の過去の数値の十分な回数分を記録したもので、過去のアプリケーションのメソッド数平均２１３は過去のアプリケーションのメソッド数２１２の全回数分の平均値を算出したものである。
【００３８】
続いて、高負荷リソース原因メソッド特定部１９０は、メソッド回数が増減しているメソッド、特に、メソッド数平均２１３よりもメソッド回数が増加しているメソッドを特定する。そして、高負荷リソース原因メソッド特定部１９０は、特定したメソッドをログ記憶部２２０に出力して記憶する。
【００３９】
なお、ログ記憶部２２０は、上述したように特定した、負荷が大きく上がったリソースと、アプリケーションのメソッド数２１１と、を記憶する記憶領域である。また、ログ記憶部２２０は、後述するように、停止している可能性のあるユーザスレッドのスレッドＩＤを記憶する記憶領域でもある。
【００４０】
［動作］
次に、上述した高負荷リソース特定装置２の動作を、図６乃至図７を参照して説明する。まず、取得部１１０が計算機システム１から取得したスレッドダンプ１０１について、分類部１２０が各スタックトレースの先頭行のみからピックアップしたメソッドを、分類用テーブル１３１と照らし合わせることで、対象となるリソースに応じて分類する。このとき、各スタックトレースの先頭行のみをピックアップするため、例えば、スレッドダンプに１０スレッド存在する場合は、１０行ピックアップされることとなる。
【００４１】
分類の例として、図６を参照すると、スレッドダンプの先頭（図６の★部分）に「java.net.SocketInputStream.socketRead0」とあり、socketRead0（ソケットリード）はネットワークIOに関する処理であるため、リソース「ネットワークＩＯ」に関する処理として分類する。他の例として、「java.io.FileInputStream」という文字列が含まれていた場合、java.io.FileInputStreamクラスはファイルアクセスに関するクラスなので、ディスクIOに関する処理として分類する。他にも、java.lang.System.arraycopyとあれば、配列コピーに関するメソッドなのでメモリコピーに分類する。
【００４２】
また、先頭行がロック解除待ちを表している場合（「waiting to lock <オブジェクトID> クラス名」という行である場合）、スタックトレースをリソースに分類可能なメソッドまで遡るか、オブジェクトIDからロックをしている行（locked <オブジェクト名> クラス名）を検索し、そこからさらにリソース分類可能な処理まで遡る。分類用テーブル１３１はこれらの分類をするためのメソッドと、そのメソッドがアクセスするリソースの紐づけが記述されている情報である。
【００４３】
こうして各ユーザスレッドに対してピックアップ・分類した情報を、分類後のスタックトレース１４１として分類後のスタックトレース記憶部１４０に記憶する。また、もともと記憶されていた分類後のスタックトレース１４１は前回分分類後のスタックトレース１４２として退避する。
【００４４】
次に、リソース間スタックトレース比率算出部１５０にて分類後のスタックトレース１４１を集計し、集計結果からリソース間スタックトレース比率１６１を算出して比率記憶部１６０に記憶する。例えば、１０スレッド存在するとして、分類後のスタックトレース１４１は１０行となるが、そのうちディスクIO、ネットワークIO、メモリコピー、キー入力の比率がそれぞれ4行、3行、2行、1行であった場合、リソース間のスタックトレース比率１６１は、40%：30%：20%：10%となる。また、もともと記憶されていたリソース間スタックトレース比率１６１は、過去のリソース間スタックトレース比率１６２の最も新しいものとして退避する（下記例の「0.」）。過去のリソース間のスタックトレース比率１６２の最も古いスタックトレース比率１６１（下記例の「5.」）は削除して、0.〜4.の平均値をリソースごとに算出する。
【００４５】
（例）
・既に記憶されていた前回分のリソース間のスタックトレース比率１６１
0. ディスクIO：ネットワークIO：メモリコピー：キー入力＝40%：30%：20%：10%
→過去のリソース間のスタックトレース比率162の最も新しいものとして退避する
・過去のリソース間スタックトレース比率１６２（新しい順）
1. ディスクIO：ネットワークIO：メモリコピー：キー入力＝30%：40%：10%：20%
2. ディスクIO：ネットワークIO：メモリコピー：キー入力＝30%：40%：20%：10%
3. ディスクIO：ネットワークIO：メモリコピー：キー入力＝50%：20%：10%：20%
4. ディスクIO：ネットワークIO：メモリコピー：キー入力＝20%：50%：20%：10%
5. ディスクIO：ネットワークIO：メモリコピー：キー入力＝30%：30%：30%：10%
→もっとも古い「5.」は削除する。
・平均値（0.〜4.の平均）
ディスクIO：ネットワークIO：メモリコピー：キー入力＝34%：36%：16%：14%
→過去のリソース間のスタックトレース比率平均１６３として記録する。
【００４６】
次に、高負荷リソース特定部１７０と高負荷リソース原因メソッド特定部１９０の処理について、図７を用いて詳細に説明する。ここでは、リソース間スタックトレース比率１６１、過去のリソース間のスタックトレース比率平均１６３、高負荷リソース判定用閾値１８１の値を用いて、以下の（例１）、（例２）の場合を説明する。また、説明中(a)〜(i)は、図７の各フローの(a)〜(i)に該当する。なお、高負荷リソース判定用閾値１８１は大きくリソース負荷が変わったと判定できる十分な大きさの値が設定されていることを前提とする。
【００４７】
（例１）
リソース間スタックトレース比率１６１の前回からの変化が、高負荷リソース判定用閾値１８１を越えることで、リソースの負荷が大きく上がったと判定し、そのリソースと、ユーザスレッドで実行されるアプリケーションのメソッドの数（前回からの増減を含む）をログ出力する例を挙げる。こうすることで、OSのコマンドを使って監視する手法ではリソースの負荷が上がっていることが計測値に反映されない場合でも、負荷の上がったリソースと、その原因となっている可能性のあるアプリケーションのメソッドを特定することができる。
【００４８】
・リソース間スタックトレース比率１６１（最新リソース間比率）
ディスクIO：ネットワークIO：メモリコピー：キー入力＝10%：70%：15%：5%
・過去のリソース間のスタックトレース比率平均１６３（過去リソース間比率）
ディスクIO：ネットワークIO：メモリコピー：キー入力＝34%：36%：16%：14%
・高負荷リソース判定用閾値181：30%
【００４９】
(a) 高負荷リソース特定部１７０で、リソース間スタックトレース比率１６１と過去のリソース間スタックトレース比率平均１６３の差を算出して、0以上の値をピックアップする。0以上の値のみピックアップする理由として、前回からスタックトレースの先頭行への出力が増えたリソースについては、各ユーザスレッドでそのリソースに対するアクセス待ちが発生している（スレッドダンプを出力したまま待っている）と考えられるためである。この時、他リソースの処理頻度は相対的に下がっていることが想定される。
ディスクIO：ネットワークIO：メモリコピー：キー入力＝-24%：+34%：-1%：-9%
【００５０】
(b) (a)でピックアップした値について、高負荷リソース判定用閾値１８１（30%）以上かどうかを判定する。0以上の値はネットワークIOで+34%なのでtrueとなる。
【００５１】
(c) 続いて、既に記憶されている前回分のアプリケーションのメソッド数２１１を過去のアプリケーションのメソッド数２１２の最も新しいものとして退避し、過去のアプリケーションのメソッド数２１２の中で最も古いものは削除して、0.〜4.の平均値を算出し、過去のアプリケーションのメソッド数平均２１３として記録する。具体例を以下に示す。
【００５２】
（例）
・既に記憶されていた前回分のアプリケーションのメソッド数２１１
0. メソッドX：メソッドY：メソッドZ＝4回：1回：1回
→過去のアプリケーションのメソッド数２１２の最も新しいものとして退避する。
・過去のアプリケーションのメソッド数２１２（新しい順）
1. メソッドX：メソッドY：メソッドZ＝3回：3回：0回
2. メソッドX：メソッドY：メソッドZ＝4回：2回：1回
3. メソッドX：メソッドY：メソッドZ＝2回：3回：2回
4. メソッドX：メソッドY：メソッドZ＝2回：1回：1回
5. メソッドX：メソッドY：メソッドZ＝4回：2回：1回
→もっとも古い「5.」は削除する。
・平均値（0.〜4.の平均）
メソッドX：メソッドY：メソッドZ＝3回：2回：1回
→アプリケーションのメソッド数平均２１３として記録する。
【００５３】
(d) アプリケーションのメソッドのリスト２０１と照らし合わせながら、スレッドダンプ１０１のユーザスレッドのスレッドダンプを遡り、もっとも深い（先頭に近い）アプリケーションのメソッドを見つける。これをプロセス１００上のユーザスレッド全てに対して行い、アプリケーションのメソッドごとに数を集計する。さらに、過去のアプリケーションのメソッド数平均２１３と比較して前回からの増減数を求め、アプリケーションのメソッド数２１１として記録する。
【００５４】
（例）
今回の集計結果がメソッドX = 5回、メソッドY = 1回、メソッドZ = 2回で、過去のアプリケーションのメソッド数平均２１３がメソッドX = 3回、メソッドY = 2回、メソッドZ = 1回だったとする。すると、アプリケーションのメソッド数２１１は「メソッドX = 5回(＋2回)、メソッドY = 1回（-1回）、メソッドZ = 2回（＋1回）」と記録する。
【００５５】
アプリケーションのメソッド数を集計する理由として、特定のリソースの負荷が大きく上がったタイミングで動作しているメソッドは、リソースの負荷を上げている原因となっている可能性があるためである。
【００５６】
(e) 負荷の大きく上がったリソースのリソース名と、アプリケーションのメソッド数２１１をログ記憶部２２０に出力する。
【００５７】
（例２）
リソース間のスタックトレース比率１６１が前回から変化がないことを検出し、スタックトレースの「state」から、停止してしまっている可能性のあるユーザスレッドがあることと、アプリケーションのメソッドの数（前回からの増減を含む）をログ出力する例を挙げる。こうすることで、従来の課題に記載したOSのコマンドを使って監視する手法によって得られる数値にまったく変化がない場合に、ユーザスレッドが動作した上で変化が無いのか、または、ユーザスレッド自体が停止している可能性があるのか、を判断する情報を得ることができる。
【００５８】
・リソース間のスタックトレース比率１６１
ディスクIO：ネットワークIO：メモリコピー：キー入力＝30%：50%：20%：0%
・過去のリソース間のスタックトレース比率１６２
ディスクIO：ネットワークIO：メモリコピー：キー入力＝30%：50%：20%：0%
・高負荷リソース判定用閾値１８１：30%
【００５９】
(a) 高負荷リソース特定部１７０で、リソース間のスタックトレース比率１６１と過去のリソース間のスタックトレース比率平均１６３の差を算出して、0以上の値をピックアップする。
ディスクIO：ネットワークIO：メモリコピー：キー入力＝±0%：±0%：±0%：±0%
(b) (a)でピックアップした値について、高負荷リソース判定用閾値１８１（40%）と比較して大きいかどうかを判定する。すべてのリソースについて差は±0なので比較結果は「false」となり、(f)へ遷移する。
【００６０】
(f) 差（±0%）が0より大きいかどうかを判定する。「false」なので、(g)に遷移する。
(g) 分類後のスタックトレース１４１と前回分分類後のスタックトレース１４２を取得してスレッドＩＤを比較し、同一のスレッドＩＤが存在すれば、そのうちユーザスレッドの「state」を参照する。
(h) (i)で参照したスレッドＩＤが同一であるユーザスレッドの「state」を確認し、前回から「BLOCKED」か「WAITING」のままであるユーザスレッドがあれば、(i)に遷移する。
(i) 停止している可能性のあるユーザスレッドが存在することと、「state」が前回から「BLOCKED」か「WAITING」のままであるスレッドのスレッドＩＤをログ記憶部２２０に記録する。
【００６１】
以上のように、本発明によると、計算機システムのOSのコマンドでリソース負荷が上がったことを検出できない場合や、計算機システムの仕様理解度が低い場合であっても、各スタックトレースの先頭行を確認するだけで負荷の大きく上がったリソースを特定することができる。また、同様に計算機システムの仕様理解度が低い場合であっても、負荷の高くなった原因となっている可能性のあるアプリケーションのメソッドを検出できる。
【００６２】
つまり、本発明を用いることで、スレッドダンプ中の各スタックトレースの先頭行のみ参照するといった簡易な方法で、負荷が大きく上がっているリソースを特定することができる。その結果、仮想環境などの対象システムへの理解度が低い場合であっても、適切に対応することができる。
【００６３】
＜実施形態２＞
本発明の第２の実施形態を、図８乃至図１０を参照して説明する。図８乃至図９は、実施形態２における情報処理システムの構成を説明するための図である。図１０は、高負荷リソース特定装置の動作を説明するための図である。
【００６４】
本実施形態では、同一アプリケーションが動作している複数のコンテナが存在する環境である場合を説明する。そして、特定のコンテナのスレッドダンプから集計した各リソースに関する処理の比率が、そのコンテナを含む複数のコンテナにおける比率の平均から大きくかけ離れていないか監視することで、負荷が大きく上がっているリソースを特定する。
【００６５】
図８乃至図９に示すように、本発明の第２の実施形態では、計算機システム１０が、同一のアプリケーションが動作している複数のコンテナ100a,100b,100cを備えており、各コンテナ100a,100b,100cに含まれるスレッドダンプ101a,101b,101cとログ記憶部102a,102b,102cとを備えている。
【００６６】
そして、高負荷リソース特定装置２０は、装備された演算装置にプログラムが組み込まれることで構築された、取得部１１０、分類部１２０、リソース間スタックトレース比率算出部１５０とコンテナ間スタックトレース比率平均算出部１５２からなるスタックトレース比率算出部１５０、高負荷リソース特定部１７０、高負荷リソース原因メソッド特定部１９０、を備えている。
【００６７】
また、高負荷リソース特定装置２０は、装備された記憶装置に形成された、分類用テーブル１３１を記憶する分類用テーブル記憶部１３０、分類後のスタックトレース141a,141b,141cを記録する分類後のスタックトレース記憶部１４０、リソース間のスタックトレース比率161a,161b,161cと過去のリソース間スタックトレース比率162a,162b,162cと過去のリソース間のスタックトレース比率の全コンテナ平均163から構成される比率記憶部160、高負荷リソース特定用閾値181を記憶する閾値記憶部180、アプリケーションのメソッドのリスト201を記憶するアプリケーションのメソッドのリスト記憶部200、アプリケーションのメソッド数211と過去のアプリケーションのメソッド数212と過去のアプリケーションのメソッド数平均213を記憶するアプリケーションのメソッド数記憶部210、ログ記憶部220から構成される。なお、上述した各構成は、実施形態１で説明したものとほぼ同様の構成である。
【００６８】
上記取得部110は、各コンテナからスレッドダンプ101a,101b,101cを取得する。そして、分類部120が分類用テーブル131を参照しながら、各スレッドダンプ内の各スタックトレースの各先頭行のみピックアップしたものを、対応するリソースごとに分類する。分類した情報は、分類後のスタックトレース141a,141b,141cとして分類後のスタックトレース記憶部140に記録する。
【００６９】
次に、リソース間のスタックトレース比率算出部150が、分類後のスタックトレース141a,141b,141cを集計し、集計結果からリソース間のスタックトレース比率161a,161b,161cを算出して比率記憶部160に記録する。この時、既に記憶されていたリソース間のスタックトレース比率161a,161b,161cは過去のリソース間のスタックトレース比率162a,162b,162cの最も新しいものとして退避し（下記例の0a,0b,0c）、過去のリソース間のスタックトレース比率162a,162b,162c の最も古いスタックトレース比率161a,162b,162cは削除後に（下記例の5a,5b,5c）、過去のリソース間のスタックトレース比率162a,162b,162cに含まれるすべてのリソース間のスタックトレース比率（下記例の0a〜4a、0b〜4b、0c〜4cすべて）の平均値を算出し、過去のリソース間のスタックトレース比率の全コンテナ平均163として記録する。
【００７０】
・既に記憶されていた前回分のリソース間のスタックトレース比率１６１ａ
0a. ディスクIO：ネットワークIO：メモリコピー：キー入力＝40%：30%：20%：10%
・既に記憶されていた前回分のリソース間のスタックトレース比率１６１ｂ
0b. ディスクIO：ネットワークIO：メモリコピー：キー入力＝30%：40%：10%：20%
・既に記憶されていた前回分のリソース間のスタックトレース比率１６１ｃ
0c. ディスクIO：ネットワークIO：メモリコピー：キー入力＝40%：40%：15%：5%
→それぞれ過去のリソース間のスタックトレース比率162a,162b,162cの最も新しいものとして退避する。
【００７１】
・過去のリソース間のスタックトレース比率１６２ａ（新しい順）
1a. ディスクIO：ネットワークIO：メモリコピー：キー入力＝30%：40%：10%：20%
2a. ディスクIO：ネットワークIO：メモリコピー：キー入力＝30%：40%：20%：10%
3a. ディスクIO：ネットワークIO：メモリコピー：キー入力＝50%：20%：10%：20%
4a. ディスクIO：ネットワークIO：メモリコピー：キー入力＝20%：50%：20%：10%
5a. ディスクIO：ネットワークIO：メモリコピー：キー入力＝30%：30%：30%：10%
・過去のリソース間のスタックトレース比率１６２ｂ（新しい順）
1b. ディスクIO：ネットワークIO：メモリコピー：キー入力＝30%：50%：10%：10%
2b. ディスクIO：ネットワークIO：メモリコピー：キー入力＝35%：35%：15%：15%
3b. ディスクIO：ネットワークIO：メモリコピー：キー入力＝50%：35%：10%：5%
4b. ディスクIO：ネットワークIO：メモリコピー：キー入力＝25%：60%：5%：10%
5b. ディスクIO：ネットワークIO：メモリコピー：キー入力＝45%：35%：5%：15%
・過去のリソース間のスタックトレース比率１６２ｃ（新しい順）
1c. ディスクIO：ネットワークIO：メモリコピー：キー入力＝40%：30%：20%：10%
2c. ディスクIO：ネットワークIO：メモリコピー：キー入力＝40%：30%：10%：20%
3c. ディスクIO：ネットワークIO：メモリコピー：キー入力＝30%：50%：10%：10%
4c. ディスクIO：ネットワークIO：メモリコピー：キー入力＝50%：20%：10%：20%
5c. ディスクIO：ネットワークIO：メモリコピー：キー入力＝30%：30%：10%：30%
→もっとも古い5a,5b,5c.は削除する。
【００７２】
・平均値（0a.〜4a., 0b.〜4b., 0c.〜4c.すべての平均）
ディスクIO：ネットワークIO：メモリコピー：キー入力＝36%：38%：13%：13%
→過去のリソース間のスタックトレース比率の全コンテナ平均１６３として退避する。
【００７３】
次に、高負荷リソース特定部１７０、高負荷リソース原因メソッド特定部１９０の処理について、図１０を用いて説明する。説明中(a)〜(i)は、図９の各フローの(a).〜(i)に該当する。また、図１０上の各値は以下とする。
【００７４】
・リソース間のスタックトレース比率１６１ａ
ディスクIO：ネットワークIO：メモリコピー：キー入力＝70%：15%：10%：5%
・リソース間のスタックトレース比率１６１ｂ
ディスクIO：ネットワークIO：メモリコピー：キー入力＝30%：45%：20%：5%
・リソース間のスタックトレース比率１６１ｃ
ディスクIO：ネットワークIO：メモリコピー：キー入力＝25%：35%：15%：25%
・過去のリソース間のスタックトレース比率の全コンテナ平均１６３
ディスクIO：ネットワークIO：メモリコピー：キー入力＝36.0%：38.0%：13.0%：13.0%
・高負荷リソース判定用閾値１８１：30%
【００７５】
リソース間のスタックトレース比率161a,162b,162cそれぞれと過去のコンテナ間のスタックトレース比率の全コンテナ平均１６３との差が、高負荷リソース判定用閾値１８１を越えることで、リソース負荷が大きく上がったと判定する。そして、該当するコンテナ、リソース、コンテナ内のユーザスレッドで実行されるアプリケーションのメソッドの数（前回からの増減を含む）をログ出力する例を挙げる。こうすることで、OSのコマンドを使って監視する手法にてリソースの負荷が上がっていることが計測値に反映されない場合でも、負荷の上がったコンテナ、リソース、その原因となっている可能性のあるアプリケーションのメソッドを特定することができる。
【００７６】
(a) 高負荷リソース特定部１７０で、リソース間のスタックトレース比率161a,161b,161cそれぞれと、過去のリソース間のスタックトレース比率の全コンテナ平均163の差を算出して、0以上の値をピックアップする。
ディスクIO：ネットワークIO：メモリコピー：キー入力＝+34%：-23%：-3%：-8%
【００７７】
(b) (a)でピックアップした値について、高負荷リソース判定用閾値１８１（30%）以上の値を含むコンテナの有無を判定する。コンテナ100aのディスクIOが+34%で0以上なので、(c)へ遷移する。
【００７８】
(c) 高負荷リソース原因特定部１９０に移動し、既に記憶されている前回分のアプリケーションのメソッド数２１１を過去のアプリケーションのメソッド数２１２の最も新しいものとして退避する。そして、過去のアプリケーションのメソッド数２１２の中で最も古いものは削除し、その後、過去のアプリケーションのメソッド数２１２に含まれるすべてのアプリケーションのメソッド数の平均を算出し、過去のアプリケーションのメソッド数平均２１３として記録する。なお、具体的な算出方法は、実施形態１の場合と同様である。
【００７９】
(d) アプリケーションのメソッドのリスト２０１と照らし合わせながらユーザスレッドのスレッドダンプを遡り、もっとも深い（先頭に近い）アプリケーションのメソッドを見つける。これをスレッドダンプ101a,101b,101cすべてのユーザスレッドに対して行い、アプリケーションのメソッドごとに数を集計する。さらに、その集計結果を過去のアプリケーションのメソッド数平均２１３と比較して前回からの増減数を求め、アプリケーションのメソッド数211として記録する。なお、この処理は、実施形態１と同様である。
【００８０】
(e) (b)で特定した負荷の大きく上がったコンテナ・リソースと、(d)で記録したアプリケーションのメソッド数211を、ログ記憶部102a（ディスクIOの負荷の大きく上がったコンテナのログ出力部）に出力する。
【００８１】
以上のように、本発明によると、計算機システムが上述した構成であっても、各スタックトレースの先頭行を確認するだけで負荷の大きく上がったリソースを特定することができる。また、負荷の高くなった原因となっている可能性のあるアプリケーションのメソッドを検出できる。
【００８２】
＜付記＞
上記実施形態の一部又は全部は、以下の付記のようにも記載されうる。以下、本発明における情報処理装置（図１１参照）、プログラム、リソース特定方法の構成の概略を説明する。但し、本発明は、以下の構成に限定されない。
【００８３】
（付記１）
メソッドと、当該メソッドがアクセスするリソースと、が対応付けられたテーブルを記憶するテーブル記憶部５１０と、
計算機システムにより実行されるプロセスに含まれる複数のスレッド毎に対応する複数のスタックトレースを取得する取得部５０１と、
取得した複数の前記スタックトレース内にそれぞれ記述されたメソッドと、前記テーブルとに基づいて、プロセスの実行によりアクセスされるリソース毎の比率に応じて、所定の条件を満たすリソースを特定するリソース特定部５０２と、
を備えた情報処理装置５００。
【００８４】
（付記２）
付記１に記載の情報処理装置であって、
前記取得部は、複数のスレッド毎に対応する複数のスタックトレースを含むスレッドダンプを取得し、
前記リソース特定部は、取得した前記スレッドダンプに含まれる複数の前記スタックトレース内のそれぞれ一部に記述されたメソッドと、前記テーブルとに基づいて、所定の条件を満たすリソースを特定する、
情報処理装置。
【００８５】
（付記３）
付記２に記載の情報処理装置であって、
前記リソース特定部は、前記スレッッドダンプに含まれる複数の前記スタックトレースのそれぞれ先頭行に記述されたメソッドと、前記テーブルとに基づいて、所定の条件を満たすリソースを特定する、
情報処理装置。
【００８６】
（付記４）
付記１乃至３のいずれかに記載の情報処理装置であって、
前記リソース特定部は、過去に取得された複数の前記スタックトレース毎にそれぞれ対応するリソース間の比率を表す過去リソース間比率と、最も新しく取得された複数の前記スタックトレース毎にそれぞれ対応するリソース間の比率を表す最新リソース間比率と、を算出し、前記過去リソース間比率と前記リソース間比率とを比較して、比率の増加したリソースを特定する、
情報処理装置。
【００８７】
（付記５）
付記４に記載の情報処理装置であって、
前記リソース特定部は、前記過去リソース間比率として、過去の所定期間に取得された複数の前記スタックトレース毎にそれぞれ対応するリソース間の比率の平均値を算出し、当該過去リソース間比率に対して、前記最新リソース間比率のうち比率が増加したリソースを特定する、
情報処理装置。
【００８８】
（付記６）
付記１乃至５のいずれかに記載の情報処理装置であって、
プロセス上で動作するアプリケーションのメソッドのリストを記憶するメソッドリスト記憶部と、
取得した複数の前記スタックトレースと前記メソッドリストとに基づいて、実行されたアプリケーションのメソッドの回数を当該メソッド毎に算出し、当該メソッドの回数に応じて所定の条件を満たすメソッドを特定するメソッド特定手段と、
を備えた情報処理装置。
【００８９】
（付記７）
付記６に記載の情報処理装置であって、
前記メソッド特定手段は、実行されたアプリケーションのメソッドの回数として、取得した複数の前記スタックトレース毎にスタックが最も深いアプリケーションのメソッドの回数を当該メソッド毎に算出する、
情報処理装置。
【００９０】
（付記８）
付記６又は７に記載の情報処理装置であって、
前記メソッド特定手段は、メソッド毎のメソッド回数が増加しているメソッドを特定する、
情報処理装置。
【００９１】
（付記９）
情報処理装置に、
計算機システムにより実行されるプロセスに含まれる複数のスレッド毎に対応する複数のスタックトレースを取得する取得部と、
メソッドと当該メソッドがアクセスするリソースとが対応付けられたテーブルと、取得した複数の前記スタックトレース内にそれぞれ記述されたメソッドと、に基づいて、プロセスの実行によりアクセスされるリソース毎の比率に応じて、所定の条件を満たすリソースを特定するリソース特定部と、
を実現させるためのプログラム。
【００９２】
（付記１０）
計算機システムにより実行されるプロセスに含まれる複数のスレッド毎に対応する複数のスタックトレースを取得し、
メソッドと当該メソッドがアクセスするリソースとが対応付けられたテーブルと、取得した複数の前記スタックトレース内にそれぞれ記述されたメソッドと、に基づいて、プロセスの実行によりアクセスされるリソース毎の比率に応じて、所定の条件を満たすリソースを特定する、
リソース特定方法。
【００９３】
なお、上述したプログラムは、記憶装置に記憶されていたり、コンピュータが読み取り可能な記録媒体に記録されている。例えば、記録媒体は、フレキシブルディスク、光ディスク、光磁気ディスク、及び、半導体メモリ等の可搬性を有する媒体である。
【００９４】
以上、上記実施形態等を参照して本願発明を説明したが、本願発明は、上述した実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明の範囲内で当業者が理解しうる様々な変更をすることができる。
【符号の説明】
【００９５】
１  計算機システム
２  高負荷リソース特定装置
１００  プロセス
１０１  スレッドダンプ
１１０  取得部
１２０  分類部
１３０  分類用テーブル記憶部
１３１  分類用テーブル
１４０  分類後のスタックトレース記憶部
１４１  分類後のスタックトレース
１４２  前回分分類後のスタックトレース
１５０  リソース間スタックトレース比率算出部
１６０  比率記憶部
１６１  リソース間のスタックトレース比率
１６２  過去のリソース間のスタックトレース比率
１７０  高負荷リソース特定部
１８０  閾値記憶部
１８１  高負荷リソース特定用閾値
１９０  高負荷リソース原因メソッド特定部
２００  アプリケーションのメソッドのリスト記憶部
２０１  アプリケーションのメソッドのリスト
２１０  アプリケーションのメソッド数記憶部
２１１  アプリケーションのメソッド数
２１２  過去のアプリケーションのメソッド数
２１３  過去のアプリケーションのメソッド数平均
２２０  ログ記憶部
１００ａ，１００ｂ，１００ｃ  コンテナ
１０１ａ，１０１ｂ，１０１ｃ  スレッドダンプ
１０２ａ，１０２ｂ，１０２ｃ  ログ記憶部
１４１ａ，１４１ｂ，１４１ｃ  分類後のスタックトレース
１５２  コンテナ間スタックトレース比率算出部
１６１ａ，１６１ｂ，１６１ｃ  リソース間のスタックトレース比率
１６２ａ，１６２ｂ，１６２ｃ  過去のリソース間のスタックトレース比率
１６３  過去のリソース間のスタックトレース比率の全コンテナ平均
５００  情報処理装置
５０１  取得部
５０２  リソース特定部
５１０  テーブル記憶部
【図１】
2017068299.tif 000003
【図２】
2017068299.tif 000004
【図３】
2017068299.tif 000005
【図４】
2017068299.tif 000006
【図５】
2017068299.tif 000007
【図６】
2017068299.tif 000008
【図７】
2017068299.tif 000009
【図８】
2017068299.tif 000010
【図９】
2017068299.tif 000011
【図１０】
2017068299.tif 000012
【図１１】
2017068299.tif 000013