(57)【要約】【課題】Ｇ１ＧＣ方式でのＦｕｌｌＧＣ発生を精度良く回避し、システムの安定的な稼働を図る。【解決手段】メモリ管理装置１００において、プログラム実行に伴い生成したオブジェクトを格納するメモリ１０３と、プログラムが実現する機能に対し所定の負荷テストを実行した結果、所定の性能要件を達成せず、メモリ１０３におけるオブジェクトの全格納領域１０７について、全ての使用済みオブジェクトを削除する全解放処理が発生した場合、全格納領域１０７のうち第２格納領域１０７１２の使用率に応じ、第２格納領域１０７１２、全格納領域１０７、および第１格納領域１０７１１、のいずれかのサイズを所定量拡大する処理をＪａｖａＶＭ１１１によって行う演算装置１０４を備える構成とする。【選択図】図１
2017142670.tif 000002
【特許請求の範囲】
【請求項１】
プログラム実行に伴い生成したオブジェクトを格納するメモリと、
前記プログラムが実現する機能に対し所定の負荷テストを実行した結果、所定の性能要件を達成せず、前記メモリにおけるオブジェクトの全格納領域について、全ての使用済みオブジェクトを削除する全解放処理が発生した場合、前記全格納領域のうち、所定回数以内の所定の第１解放処理を経て現在使用中のオブジェクトを格納する第２格納領域の使用率に応じ、当該第２格納領域、前記全格納領域、および前記全格納領域のうち生成直後のオブジェクトを格納する第１格納領域、のいずれかのサイズを所定量拡大する処理を実行する演算装置と、
を備えることを特徴とするメモリ管理装置。
【請求項２】
前記演算装置は、
前記サイズを所定量拡大する処理に際し、
前記第２格納領域の使用率が所定基準以上である場合、前記全格納領域のサイズを所定量拡大することで前記第２格納領域のサイズも拡大するか、または、前記第２格納領域のサイズのみを所定量拡大し、
当該拡大の結果、前記第２格納領域のサイズを当該拡大前のサイズより所定割合以上拡大出来なかった場合、前記第１格納領域と前記第２格納領域の一部とを対象とする所定の第２解放処理における前記第２格納領域での解放処理対象の領域を増加させるものである、
ことを特徴とする請求項１に記載のメモリ管理装置。
【請求項３】
前記演算装置は、
前記サイズを所定量拡大する処理に際し、
前記第２格納領域の使用率が所定基準より小さい場合、前記負荷テストの実行結果のうちレスポンスタイムが所定基準を満たしているか判定し、
当該判定の結果、レスポンスタイムが所定基準を満たしているならば、前記各解放処理による前記機能の目標停止時間の値を所定量増加させると共に前記各解放処理向けのスレッド数を増やし、前記レスポンスタイムが所定基準を満たしていないならば、前記全格納領域のサイズを所定量拡大することで前記第１格納領域および前記第２格納領域の格納領域サイズを拡大するものである、
ことを特徴とする請求項１に記載のメモリ管理装置。
【請求項４】
前記演算装置は、
前記全解放処理が発生した場合、前記サイズを所定量拡大する処理に先立ち、前記全格納領域のうち、前記第１格納領域および前記第２格納領域のいずれかのオブジェクトのうち所定時間以上にわたり使用中のオブジェクトを格納する第３格納領域での、サイズが所定基準以上のオブジェクトの存在数が所定数を越えるか判定し、
当該判定の結果、前記第３格納領域での前記オブジェクトの存在数が所定数を越えない場合に、前記サイズを所定量拡大する処理に移行し、
当該判定の結果、前記第３格納領域での前記オブジェクトの存在数が所定数を越える場合に、前記プログラムないしハードウェアの改修を示唆する通知を所定装置に出力する処理を更に実行するものである、
ことを特徴とする請求項１に記載のメモリ管理装置。
【請求項５】
プログラム実行に伴い生成したオブジェクトを格納するメモリを備えた情報処理装置が、
前記プログラムが実現する機能に対し所定の負荷テストを実行した結果、所定の性能要件を達成せず、前記メモリにおけるオブジェクトの全格納領域について、全ての使用済み
オブジェクトを削除する全解放処理が発生した場合、前記全格納領域のうち、所定回数以内の所定の第１解放処理を経て現在使用中のオブジェクトを格納する第２格納領域の使用率に応じ、当該第２格納領域、前記全格納領域、および前記全格納領域のうち生成直後のオブジェクトを格納する第１格納領域、のいずれかのサイズを所定量拡大する処理を実行する、
ことを特徴とするメモリ管理方法。
【請求項６】
前記情報処理装置が、
前記サイズを所定量拡大する処理に際し、
前記第２格納領域の使用率が所定基準以上である場合、前記全格納領域のサイズを所定量拡大することで前記第２格納領域のサイズも拡大するか、または、前記第２格納領域のサイズのみを所定量拡大し、
当該拡大の結果、前記第２格納領域のサイズを当該拡大前のサイズより所定割合以上拡大出来なかった場合、前記第１格納領域と前記第２格納領域の一部とを対象とする所定の第２解放処理における前記第２格納領域での解放処理対象の領域を増加させる、
ことを特徴とする請求項５に記載のメモリ管理方法。
【請求項７】
前記情報処理装置が、
前記サイズを所定量拡大する処理に際し、
前記第２格納領域の使用率が所定基準より小さい場合、前記負荷テストの実行結果のうちレスポンスタイムが所定基準を満たしているか判定し、
当該判定の結果、レスポンスタイムが所定基準を満たしているならば、前記各解放処理による前記機能の目標停止時間の値を所定量増加させると共に前記各解放処理向けのスレッド数を増やし、前記レスポンスタイムが所定基準を満たしていないならば、前記全格納領域のサイズを所定量拡大することで前記第１格納領域および前記第２格納領域の格納領域サイズを拡大する、
ことを特徴とする請求項５に記載のメモリ管理方法。
【請求項８】
前記情報処理装置が、
前記全解放処理が発生した場合、前記サイズを所定量拡大する処理に先立ち、前記全格納領域のうち、前記第１格納領域および前記第２格納領域のいずれかのオブジェクトのうち所定時間以上にわたり使用中のオブジェクトを格納する第３格納領域での、サイズが所定基準以上のオブジェクトの存在数が所定数を越えるか判定し、
当該判定の結果、前記第３格納領域での前記オブジェクトの存在数が所定数を越えない場合に、前記サイズを所定量拡大する処理に移行し、
当該判定の結果、前記第３格納領域での前記オブジェクトの存在数が所定数を越える場合に、前記プログラムないしハードウェアの改修を示唆する通知を所定装置に出力する処理を更に実行する、
ことを特徴とする請求項５に記載のメモリ管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メモリ管理装置およびメモリ管理方法に関するものであり、具体的には、Ｇ１ＧＣ方式でのＦｕｌｌＧＣ発生を精度良く回避し、システムの安定的な稼働を図る技術に関する。
【背景技術】
【０００２】
Ｊａｖａ（登録商標）を基盤としたｗｅｂシステムを様々な業務システムに採用する事例が増えている。一方で、Ｊａｖａプログラムが動作する環境に関し、メモリ管理を考慮したプログラム設計とパラメータチューニング等を行うとしても、稼働後の高負荷が影響してトラブル発生を招くケースが少なからず存在する。
【０００３】
例えば、Ｊａｖａプログラムの動作に際してオブジェクトはメモリのヒープ領域にロードされるが、当然ながら、使用オブジェクトのサイズや数が多ければ、このヒープ領域の使用領域も増大する。その後も更に、ヒープ領域へのオブジェクトのロードを継続すれば、いずれヒープ領域の空きは無くなり、プログラム実行が困難な事態となる。
【０００４】
そこでＪａｖａ仮想マシン（以下、ＪａｖａＶＭ）は、プログラム実行中に生成しヒープ領域にロードしたオブジェクトのうち、不要になったオブジェクトをガベージコレクション（ＧＣ：Ｇａｒｂａｇｅ  Ｃｏｌｌｅｃｔｉｏｎ。以下、ＧＣ）によって削除し、ヒープ領域を解放する。
【０００５】
このようなメモリ管理に関連する従来技術としては、例えば、コンピュータ内のプロセッサにより実行されるプログラムにより前記コンピュータ内にメモリ領域を確保し、前記プログラムの実行に応じて前記メモリ領域にデータを格納し、前記プログラムによる前記メモリ領域の解放の指示に応答して、前記プログラムの以降の実行に必要なデータが前記解放を指示された前記メモリ領域に存在するか否かをチェックし、前記チェックの結果、前記プログラムの以降の実行に必要なデータが前記メモリ領域に存在しないとき、前記メモリ領域を解放するメモリ管理方法（特許文献１参照）などが提案されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００９−３７５４７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上述のＧＣには、いくつかの種類があるが、そのうちＦｕｌｌＧＣ（ヒープ領域全体を対象として使用済みオブジェクトの削除が実行される）が発生した場合、業務システムは停止し、性能影響が大きい。特に、金融機関などミッションクリティカルな業務システムにおいてこのＦｕｌｌＧＣの発生は回避する必要がある。
【０００８】
こうした課題への新たなＧＣ方式としてＧ１ＧＣがリリースされた。Ｇ１ＧＣはＦｕｌｌＧＣを発生させずにメモリを開放することが可能である。ところが、当該Ｇ１ＧＣに基づき管理されるメモリは、従来のメモリ構造とは大きくことなるため、現在のメモリ設計手法を流用することはできない。
【０００９】
そこで本発明の目的は、Ｇ１ＧＣ方式でのＦｕｌｌＧＣ発生を精度良く回避し、システムの安定的な稼働を図る技術を提供することにある。
【課題を解決するための手段】
【００１０】
上記課題を解決する本発明のメモリ管理装置は、プログラム実行に伴い生成したオブジェクトを格納するメモリと、前記プログラムが実現する機能に対し所定の負荷テストを実行した結果、所定の性能要件を達成せず、前記メモリにおけるオブジェクトの全格納領域について、全ての使用済みオブジェクトを削除する全解放処理が発生した場合、前記全格納領域のうち、所定回数以内の所定の第１解放処理を経て現在使用中のオブジェクトを格納する第２格納領域の使用率に応じ、当該第２格納領域、前記全格納領域、および前記全格納領域のうち生成直後のオブジェクトを格納する第１格納領域、のいずれかのサイズを所定量拡大する処理を実行する演算装置と、を備えることを特徴とする。
【００１１】
また、本発明のメモリ管理方法は、プログラム実行に伴い生成したオブジェクトを格納するメモリを備えた情報処理装置が、前記プログラムが実現する機能に対し所定の負荷テストを実行した結果、所定の性能要件を達成せず、前記メモリにおけるオブジェクトの全格納領域について、全ての使用済みオブジェクトを削除する全解放処理が発生した場合、前記全格納領域のうち、所定回数以内の所定の第１解放処理を経て現在使用中のオブジェクトを格納する第２格納領域の使用率に応じ、当該第２格納領域、前記全格納領域、および前記全格納領域のうち生成直後のオブジェクトを格納する第１格納領域、のいずれかのサイズを所定量拡大する処理を実行する、ことを特徴とする。
【発明の効果】
【００１２】
本発明によれば、Ｇ１ＧＣ方式でのＦｕｌｌＧＣ発生を精度良く回避し、システムの安定的な稼働を図ることが可能となる。
【図面の簡単な説明】
【００１３】
【図１】本実施形態のメモリ管理装置の構成を示す図である。
【図２】本実施形態におけるヒープ領域の構成例を示す図である。
【図３】本実施形態の性能要件テーブルの構成例を示す図である。
【図４】本実施形態のチューニング前試算テーブルの構成例を示す図である。
【図５】本実施形態のパラメータ値算出結果テーブルの構成例を示す図である。
【図６】本実施形態のチューニング後試算テーブルの構成例を示す図である。
【図７】本実施形態のオブジェクト管理情報の構成例を示す図である。
【図８】本実施形態におけるメモリ管理方法のフロー例を示す図である。
【図９】本実施形態における出力例を示す図である。
【発明を実施するための形態】
【００１４】
−−−構成−−−
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は、本実施形態のメモリ管理装置１００の構成を示す図である。図１に示すメモリ管理装置１００は、Ｇ１ＧＣ方式でのＦｕｌｌＧＣ発生を精度良く回避し、システムの安定的な稼働を図る情報処理装置である。
【００１５】
本実施形態のメモリ管理装置１００は、そのＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）上でＪａｖａプログラムのための仮想環境を構成する、ＪａｖａＶＭ（Ｊａｖａ  Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ）が動作可能な情報処理装置である。このメモリ管理装置１００は、演算装置１０４、補助記憶装置１０１、主記憶装置１０３（メモリ）、入力装置１０５、および出力装置１０６などの適宜なハードウェアを備えている。
【００１６】
このうち主記憶装置１０３は、Ｊａｖａコンパイラ１１０、ＪａｖａＶＭ１１１、ヒー
プ領域１０７、オブジェクト管理情報１０８、及び、オペレーティングシステム１１５を保持する。一方、補助記憶装置１０１は、業務処理の実行に使用されるＪａｖａクラスファイル１１２、当該Ｊａｖａクラスファイル１１２を生成するためのＪａｖａソースファイル１１３、ＪａｖａＶＭ１１１の動作を制御するフラグやパラメータの閾値を記録するコンフィグファイル１１４、性能要件テーブル１１６、チューニング前試算テーブル１１７、パラメータ値算出結果テーブル１１８、および、チューニング後試算テーブル１１９、を含む。
【００１７】
このうちコンフィグファイル１１４に、ヒープ領域１０７における各格納領域のサイズ設定やＧＣに関する各種設定等の情報が、ＪａｖａＶＭ１１１によって書き込まれる。また、ＪａｖａＶＭ１１１は起動時にこのコンフィグファイル１１４を読み込んで、その内容に従ってヒープ領域１０７の格納領域を構成することになる。
【００１８】
ヒープ領域１０７は、図２にて示すように、大きくわけて、Ｎｅｗ領域１０７１およびＴｅｎｕｒｅｄ領域１０７２から構成されている。このＮＥＷ領域１０７１は、ＪａｖａＶＭ１１１が新たに生成したオブジェクトを格納する領域であり、Ｅｄｅｎ領域１０７１１とＳｕｒｖｉｖｏｒ領域１０７１２に分けられている。
【００１９】
このうちＥｄｅｎ領域１０７１１は、作成直後のオブジェクトを格納する領域であり、Ｓｕｒｖｉｖｏｒ領域１０７１２は、１回以上のＧＣを経て生き残った、使用中のオブジェクトを格納する領域である。
【００２０】
また、Ｔｅｎｕｒｅｄ領域１０７２は、長時間使用するオブジェクトを格納する領域であり、その中でもサイズの大きなオブジェクトを格納する領域をＨｕｍｏｎｇｏｓ領域１０７２１としている。なお、主記憶装置１０３において、Ｇ１ＧＣでのメモリ管理に際して確保されている領域には、上述のヒープ領域１０７の他に、Ｆｒｅｅ領域１０７３（領域不足に備えて使用されていない領域）、ＭｅｔａＳｐａｃｅ領域１０７４（ロードされたクラス情報やメソッド情報を格納する領域）が含まれる。
【００２１】
こうしたメモリ管理装置１００では、Ｊａｖａ言語によって記述されたＪａｖａソースファイル１１３がＪａｖａコンパイラ１１０によってコンパイルされることによって、ＪａｖａＶＭ１１１がインタプリタ実行により解釈、及び、実行可能な形式であるバイトコードで記述されたＪａｖａクラスファイル１１２が生成される。さらに、Ｊａｖａクラスファイル１１２がＪａｖａＶＭ１１１によって実行されることで、所定の業務処理が実行される。従って、Ｊａｖａクラスファイル１１２は、上述の業務処理を実行するためのプログラムといえる。いずれにしてもＪａｖａに関係する一般的な構成自体は既存のものと同様である。
【００２２】
このうちＪａｖａＶＭ１１１は、上述のヒープ領域１０７において使用済みで現在不要になったオブジェクトを削除し、当該オブジェクトが占有していたメモリ領域を解放する、いわゆるメモリ解放処理など適宜なメモリ管理機能を備える言語処理実行システムである。なお、本実施形態におけるＪａｖａＶＭ１１１は、Ｇ１ＧＣに基づくメモリ管理を実行するものとする。
【００２３】
ＪａｖａＶＭ１１１は、この他にも、バイトコード読み込み（Ｊａｖａクラスファイル１１２からメソッドのバイトコード読み込み等）、オブジェクト生成先変更（オブジェクト生成命令に係るオブジェクト生成先をヒープ領域１０７外に変更等）、メソッド実行（バイトコードの各命令に従ってメソッド実行等）、および、オブジェクト解析といった機能も従来通りに備えている。なお、これら各機能は、演算装置１０４が実行するプログラムにより実装されるものである。
【００２４】
一方、本実施形態のメモリ管理方法の実行主体たるＪａｖａＶＭ１１１におけるメモリ管理機能は、当該ＪａｖａＶＭ１１１で使用するメモリ領域を管理する機能である。このメモリ管理機能は、オブジェクト生成とＧＣ管理の各機能を含んでいる。このうちオブジェクト生成機能は、メソッド実行に伴うオブジェクト生成処理要求を受けて、ヒープ領域１０７へのオブジェクト生成を行う。この時、ヒープ領域１０７に適宜な空き領域が無く、オブジェクト生成に失敗した場合、ＪａｖａＶＭ１１１のメモリ管理機能は、ＧＣ管理機能に対してＧＣ処理を指示することになる。ＧＣ管理機能がＧＣ処理を実行することで、ヒープ領域１０７における不要なオブジェクトを削除してメモリ領域の解放を図ることになる。
【００２５】
なお、ＪａｖａＶＭ１１１のオブジェクト生成機能は、生成したオブジェクトに関して適宜なＩＤを付与し、その格納領域の情報と共にオブジェクト管理情報１０８に格納する。また、ＪａｖａＶＭ１１１のオブジェクト解析機能は、上述のＧＣ管理機能により実行されたＹｏｕｎｇＧＣ、ＭｉｘｅｄＧＣ、およびＦｕｌｌＧＣの各ＧＣに際して削除されず（つまり使用中）、生存しているオブジェクトのＧＣ経験回数をカウントし、オブジェクト管理情報１０８に格納する。
【００２６】
−−−データ等の構造−−−
続いて、本実施形態のメモリ管理装置１００が用いるテーブル等の構造について説明する。図３に、本実施形態における性能要件テーブル１１６の一例を示す。性能要件テーブル１１６は、上述のＪａｖａクラスファイル１１２により実行される業務処理、すなわち金融機関等における各業務システムでの処理に関して、当該金融機関等のシステム管理者などが指定した性能要件を格納したテーブルである。そのデータ構造は、要件を一意に特定する項目ＩＤをキーとして、当該要件の項目名称、値、単位といったデータから成るレコードの集合体である。
【００２７】
また、図４に本実施形態のチューニング前試算テーブル１１７の一例を示す。チューニング前試算テーブル１１７は、本実施形態における負荷テストの実行前に、ＪａｖａＶＭ１１１が、上述の性能要件テーブル１１６に基づいて算定した、ヒープ領域１０７における各格納領域のサイズ等に関する試算値（すなわちＪａｖａＶＭ１１１はこの試算値をコンフィグファイル１１４に設定して負荷テストを実行する）を格納したテーブルである。そのデータ構造は、各試算項目を一意に特定する試算ＩＤをキーとして、算出項目、その値、単位、および算出式といったデータから成るレコードの集合体である。
【００２８】
また、図５に本実施形態のパラメータ値算出結果テーブル１１８の一例を示す。パラメータ値算出結果テーブル１１８は、上述のチューニング前試算テーブル１１７に基づくメモリ設計後に、本実施形態のメモリ管理方法を実施した結果、Ｇ１ＧＣにおける各パラメータに関して算定した値を格納したテーブルである。そのデータ構造は、パラメータを一意に特定する項目ＩＤをキーとして、パラメータ名、その値、単位、および備考といったデータから成るレコードの集合体である。
【００２９】
また、図６に本実施形態のチューニング後試算テーブル１１９の一例を示す。チューニング後試算テーブル１１９は、本実施形態のメモリ管理方法による、上述のチューニング前試算テーブル１１７に基づくメモリ設計と上述のＧ１ＧＣの各パラメータの特定の結果、ヒープ領域１０７の各格納領域のサイズを格納したテーブルである。そのデータ構造は、各格納領域の名をキーとして、当該格納領域のサイズおよびその単位、といったデータから成るレコードの集合体である。
【００３０】
また、図７に本実施形態のオブジェクト管理情報１０８の一例を示す。このオブジェク
ト管理情報１０８は、既に述べたように、オブジェクト生成に伴い付与した、各オブジェクトのＩＤをキーとして、その格納領域、各ＧＣの経験回数といったデータから成るレコードの集合体である。
【００３１】
−−−フロー例−−−
以下、本実施形態におけるメモリ管理方法の実際手順について図に基づき説明する。以下で説明するメモリ管理方法に対応する各種動作は、メモリ管理装置１００におけるＪａｖａＶＭ１１１により実現される。
【００３２】
図８は、本実施形態におけるメモリ管理方法のフロー例を示す図である。なお、ＪａｖａＶＭ１１１によるＧ１ＧＣに沿ったメモリ管理のうち、本実施形態のメモリ管理方法に関するものについて説明する。よってＧ１ＧＣに基づくメモリ管理であっても既存技術に関しては適宜省略する。また、処理の実行主体は、ハードウェアとしてはメモリ管理装置１００であるが、その処理を行うプログラムはＪａｖａＶＭ１１１であるため、以降の説明ではＪａｖａＶＭ１１１を処理の実行主体として示すものとする。
【００３３】
まずＪａｖａＶＭ１１１は、性能要件テーブル１１６を読み込んで、当該性能要件テーブル１１６の各値を、チューニング前試算テーブル１１７における対応項目の算定式に適用することで、ヒープ領域１０７における各格納領域のサイズや、負荷テストの実行時における各種目標値を試算する（ｓ１００）。
【００３４】
ＪａｖａＶＭ１１１は、例えば、「マシン１台あたりの目標ＴＰＳ」について、その算定式に従って、性能要件テーブル１１６の項目ＩＤ「０１」の目標ＴＰＳ「１０００」を、項目ＩＤ「０９」のマシン台数「２」で除算し、５００（Ｔｒｎ／ｓ）と算定する。
【００３５】
また、ＪａｖａＶＭ１１１は、「マシン１台あたり同時接続数」について、その算定式に従って、性能要件テーブル１１６の項目ＩＤ「０３」の最大同時接続数「２００」を、項目ＩＤ「０９」のマシン台数「２」で除算し、１００（本）と算定する。
【００３６】
また、ＪａｖａＶＭ１１１は、「目標レスポンス」について、その算定式に従って、上述で既に求めた「マシン１台あたり同時接続数」の「１００」を、「マシン１台あたりの目標ＴＰＳ」の「５００」で除算し、「０．２秒」と算定する。
【００３７】
また、ＪａｖａＶＭ１１１は、Ｅｄｅｎ領域のサイズすなわちＥｄｅｎサイズについて、その算定式に従って、性能要件テーブル１１６の項目ＩＤ「０５」のＣｏｐｙＧＣ発生間隔「１０」に、項目ＩＤ「０１」の目標ＴＰＳ「１００」を乗算し、この乗算値「１０００」に、項目ＩＤ「０２」のトランザクションあたりの使用メモリの「５」（ＭＢ）と項目ＩＤ「０８」のセッションオブジェクトサイズ（平均）の「３２」（ＫＢ）の合計値を乗算し、５０３２（ＭＢ）と算定する。
【００３８】
また、ＪａｖａＶＭ１１１は、Ｓｕｒｖｉｖｏｒ領域のサイズすなわちＳｕｒｖｉｖｏｒサイズについて、その算定式に従って、上述で得たＥｄｅｎサイズ「５０３２」（ＭＢ）に、性能要件テーブル１１６の項目ＩＤ「０４」のメモリ平均生存率の「５０」（％）と、１．２５を乗算し、３１４５（ＭＢ）と算定する。
【００３９】
また、ＪａｖａＶＭ１１１は、Ｔｅｎｕｒｅｄ領域のサイズすなわちＴｅｎｕｒｅｄサイズについて、その算定式に従って、性能要件テーブル１１６の項目ＩＤ「０７」のＯｌｄ領域の増加量「２０」（ＫＢ／ＧＣ）に、項目ＩＤ「０６」のＦｕｌｌＧＣ発生間隔「１」（回）を乗算し、この乗算値「２０」（ＫＢ）に、項目ＩＤ「１１」のリダイレクタとの通信オブジェクトサイズ「１２８」（ＫＢ）と、項目ＩＤ「０８」のセッションオブ
ジェクトサイズ（平均）の「３２」（ＫＢ）と、製品使用サイズの「１００ＭＢ」と、上述で得たＥｄｅｎサイズ「５０３２」（ＭＢ）と、Ｓｕｒｖｉｖｏｒサイズ「３１４５」（ＭＢ）とを合算し、８２７７（ＭＢ）と算定する。
【００４０】
また、ＪａｖａＶＭ１１１は、ヒープ領域のサイズすなわちヒープサイズについて、その算定式に従って、上述で得たＥｄｅｎサイズ「５０３２」（ＭＢ）、Ｓｕｒｖｉｖｏｒサイズ「３１４５」（ＭＢ）、およびＴｅｎｕｒｅｄサイズ「８２７７」（ＭＢ）を合算し、当該合算値「１６４５４」（ＭＢ）を２倍し、「３２９０８」（ＭＢ）と算定する。
【００４１】
次に、ＪａｖａＶＭ１１１は、ここまでで試算した、ヒープサイズ、Ｅｄｅｎサイズ、Ｓｕｒｖｉｖｏｒサイズ、およびＴｅｎｕｒｅｄサイズ、の各値をコンフィグファイル１１４に設定する（ｓ１０１）。
【００４２】
続いてＪａｖａＶＭ１１１は、Ｊａｖａクラスファイル１１２の実行で実行される業務処理に関して、例えば通常は過負荷となる所定量の処理用データを入力とする負荷テスト（負荷テスト自体は既存手法を採用すればよい）を実行する（ｓ１０２）。ＪａｖａＶＭ１１１は、この負荷テストに伴うログ（Ｊａｖａログ。以下Ｊａｖａログ）を補助記憶装置１０１など適宜な記憶装置に蓄積するものとする。
【００４３】
こうした負荷テストに伴い、ＪａｖａＶＭ１１１はオブジェクトを生成して、ヒープ領域１０７に格納することなる。また過負荷な入力データに対する処理を行うことから、通常より多くのオブジェクトが生成され、ヒープ領域１０７の各格納領域がオブジェクトで充満している可能性が高い。つまりＧＣが発生しやすい状態が予想される。なお、こうしたヒープ領域１０７でのオブジェクト格納とＧＣに伴う格納領域間でのオブジェクト移動やオブジェクト削除といった処理自体は、Ｇ１ＧＣでのメモリ管理手法に則ったものとなる。
【００４４】
また、ＪａｖａＶＭ１１１は、上述の負荷テストの結果、上述の業務処理において観測されたＴＰＳ（負荷テストのツールから得られる）は目標ＴＰＳ以上であったか、すなわち目標ＴＰＳを達成出来たか判定する（ｓ１０３）。
【００４５】
この判定の結果、目標ＴＰＳを達成出来た場合（ｓ１０３：ｙ）、ＪａｖａＶＭ１１１は、上述のステップｓ１００で算定してｓ１０１でコンフィグファイル１１４に設定した試算値が適切なものであったと認識し、以降の処理を終了する。
【００４６】
他方、上述の判定の結果、目標ＴＰＳを達成出来なかった場合（ｓ１０３：ｎ）、ＪａｖａＶＭ１１１は、上述の負荷テストに際してＦｕｌｌＧＣが発生したか、上述のＪａｖａログに基づき判定する（ｓ１０４）。
【００４７】
この判定の結果、ＦｕｌｌＧＣが発生したことが判明した場合（ｓ１０４：ｙ）、ＪａｖａＶＭ１１１は、Ｈｕｍｏｎｇｏｓ領域１０７２１での、サイズが所定基準以上のオブジェクトの存在数が所定数を越えるか判定する（ｓ１０５）。
【００４８】
このサイズの所定基準は、例えば、Ｓｕｒｖｉｖｏｒ領域のサイズの半分のサイズ、すなわち上述の試算値の例であれば、３１４５（ＭＢ）の半分である、１５７２（ＭＢ）が基準となる。また、当該オブジェクトの存在数の基準は、例えば、該当オブジェクトの総サイズがＴｅｎｕｒｅｄ領域１０７２の８０％以上を占める状態となった場合のオブジェクト数となる。
【００４９】
この判定の結果、Ｈｕｍｏｎｇｏｓ領域１０７２１での、サイズが所定基準以上のオブ
ジェクトの存在数が所定数を越えることが判明した場合（ｓ１０５：ｙ）、ＪａｖａＶＭ１１１は、当該業務処理に対応するＪａｖａプログラムないしメモリ管理装置１００のハードウェアの改修を示唆する通知を、出力装置１０６に出力し（ｓ１０６）、処理をステップｓ１００に戻す。この通知を行おう状態とは、当該メモリ管理装置１００が持っているメモリサイズ（主記憶装置１０３の記憶領域サイズ）では、当該Ｊａｖａプログラムの実行に伴うオブジェクトを格納しきれないため、オブジェクトの分割や主記憶装置１０３の増設といった根本的な対応が必要な状態である。
【００５０】
他方、上述の判定の結果、Ｈｕｍｏｎｇｏｓ領域１０７２１での、サイズが所定基準以上のオブジェクトの存在数が所定数を越えないことが判明した場合（ｓ１０５：ｎ）、ＪａｖａＶＭ１１１は、Ｓｕｒｖｉｖｏｒ領域１０７１２が新たにオブジェクトを収容仕切れず、Ｅｄｅｎ領域１０７１１のオブジェクトがＴｅｎｕｒｅｄ領域１０７２に直接移行している状況、すなわち、Ｓｕｒｖｉｖｏｒ領域１０７１２の溢れ状態にあるか、Ｊａｖａログに基づき判定する（ｓ１０７）。
【００５１】
この判定の結果、Ｓｕｒｖｉｖｏｒ領域１０７１２の溢れ状態が判明した場合（ｓ１０７：ｙ）、ＪａｖａＶＭ１１１は、ヒープ領域１０７のサイズを拡大することでＳｕｒｖｉｖｏｒ領域１０７１２の拡大するか、当該拡大が出来ない場合は、Ｅｄｅｎ領域１０７１１のサイズとＳｕｒｖｉｖｏｒ領域１０７１２のサイズとの比率を変更して、Ｓｕｒｖｉｖｏｒ領域１０７１２のサイズのみ拡大する（ｓ１０８）。
【００５２】
なお、ヒープ領域１０７のサイズ拡大が出来ない場合とは、例えば、主記憶装置１０３の記憶領域の余裕がそもそも無い状況が想定出来る。また、Ｅｄｅｎ領域１０７１１のサイズとＳｕｒｖｉｖｏｒ領域１０７１２のサイズとの比率を変更する場合、例えば、Ｅｄｅｎサイズ：Ｓｕｒｖｉｖｏｒサイズ＝６：４とする。
【００５３】
当該Ｓｕｒｖｉｖｏｒ領域１０７１２のサイズ拡大の結果、Ｓｕｒｖｉｖｏｒ領域１０７１２のサイズを当該拡大前のサイズより、例えば５％以上拡大出来た場合（ｓ１０９：ｙ）、ＪａｖａＶＭ１１１は、処理をステップｓ１００に戻す。
【００５４】
他方、Ｓｕｒｖｉｖｏｒ領域１０７１２のサイズを、５％以上拡大出来なかった場合（ｓ１０９：ｎ）、ＪａｖａＶＭ１１１は、ＭｉｘｅｄＧＣにおけるＳｕｒｖｉｖｏｒ領域１０７１２での対象リージョン（解放処理対象の領域）を増加させる（ｓ１１０）。この処理は、Ｇ１ＧＣにおける、「−ＸＸ：ＣｏｎｃＧＣＴｈｒｅａｄｓ」オプションを、「＋１」するものとなる。
【００５５】
他方、上述のステップｓ１０７での判定の結果、Ｓｕｒｖｉｖｏｒ領域１０７１２は溢れ状態でないことが判明した場合（ｓ１０７：ｎ）、ＪａｖａＶＭ１１１は、上述の負荷テストの実行結果のうちレスポンスタイムが、チューニング前試算テーブル１１７における「目標レスポンス」の値を満たしているか判定する（ｓ１１１）。
【００５６】
この判定の結果、レスポンスタイムが「目標レスポンス」の値を満たしていることが判明した場合（ｓ１１１：ｙ）、ＪａｖａＶＭ１１１は、パラメータ値算出結果テーブル１１８における「ＭａｘＧＣＰａｕｓｅＭｉｌｌｉｓ」、すなわちＧＣ目標停止時間の値を増加させ（ｓ１１２）、ステップｓ１００に処理を戻す。この増加量は、例えば、「目標レスポンス」の値−レスポンスタイム（上述の負荷テストの実行時における観測値）−０．０１、の値とする。
【００５７】
また、このステップｓ１１２において、ＪａｖａＶＭ１１１は、このＧＣ目標停止時間の値の増加と共に、パラメータ値算出結果テーブル１１８における「ＰａｒａｌｌｅｌＧ
ＣＴｈｒｅａｄｓ」の値、すなわちＧＣ向けのスレッド数を「＋１」する。
【００５８】
また、上述の判定の結果、レスポンスタイムが「目標レスポンス」の値を満たしていないことが判明した場合（ｓ１１１：ｎ）、ＪａｖａＶＭ１１１は、Ｅｄｅｎ領域１０７１１のサイズが例えば１．２倍になるよう、ヒープ領域１０７のサイズを拡大し（ｓ１１３）、処理をステップｓ１００に戻す。
【００５９】
他方、上述のステップｓ１０４での判定の結果、ＦｕｌｌＧＣが発生しなかったことが判明した場合（ｓ１０４：ｎ）、ＪａｖａＶＭ１１１は、Ｊａｖａの同時実行数の上限に達しているか判定する（ｓ１１４）。当該判定の結果、上限数に達していることが判明した場合（ｓ１１４：ｙ）、ＪａｖａＶＭ１１１は、マシン１台あたりの同時実行スレッド数を例えば「＋３」し（ｓ１１５）、処理をステップｓ１００に戻す。一方、上述の判定の結果、上限数に達していないことが判明した場合（ｓ１１４：ｎ）、ＪａｖａＶＭ１１１は、ｗｅｂサーバのＭａｘＣｌｉｅｎｔを拡大するよう要請するメッセージを出力装置１０６に出力し（ｓ１１６）、処理をステップｓ１００に戻す。なお、上述のステップｓ１１４〜ｓ１１６の処理は、ＦｕｌｌＧＣの発生が無い状態に関するものであり、本実施形態のメモリ管理方法において必須構成ではない。
【００６０】
ＪａｖａＶＭ１１１は、以上のようにヒープ領域１０７に関するチューニングを実行し、改めてステップｓ１００からフローを再実行することで、コンフィグファイル１１４に設定したチューニング後の値（各格納領域のサイズ等）が、目標ＴＰＳを達成出来る適切なものとなっているか検証を繰り返すことができる。チューニング完了した結果は、例えば、図９の出力例９００に示すように、ＪａｖａＶＭ１１１が出力装置１０６にてチューニング前後での各設定値を比較表示として示す。
【００６１】
以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
【００６２】
こうした本実施形態によれば、Ｇ１ＧＣ方式でのＦｕｌｌＧＣ発生を精度良く回避し、システムの安定的な稼働を図ることが可能となる。
【００６３】
本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態のメモリ管理装置において、前記演算装置は、前記サイズを所定量拡大する処理に際し、前記第２格納領域の使用率が所定基準以上である場合、前記全格納領域のサイズを所定量拡大することで前記第２格納領域のサイズも拡大するか、または、前記第２格納領域のサイズのみを所定量拡大し、当該拡大の結果、前記第２格納領域のサイズを当該拡大前のサイズより所定割合以上拡大出来なかった場合、前記第１格納領域と前記第２格納領域の一部とを対象とする所定の第２解放処理における前記第２格納領域での解放処理対象の領域を増加させるものである、としてもよい。
【００６４】
これによれば、第２格納領域すなわちＳｕｒｖｉｖｏｒ領域のサイズを拡大出来ない状況にも対応し、第２解放処理すなわちＭｉｘｅｄＧＣでの対象リージョンを増やしてＭｉｘｅｄＧＣ時のメモリ解放をより効率化し、よりＦｕｌｌＧＣを回避しやくできる。
【００６５】
また、本実施形態のメモリ管理装置において、前記演算装置は、前記サイズを所定量拡大する処理に際し、前記第２格納領域の使用率が所定基準より小さい場合、前記負荷テストの実行結果のうちレスポンスタイムが所定基準を満たしているか判定し、当該判定の結果、レスポンスタイムが所定基準を満たしているならば、前記各解放処理による前記機能の目標停止時間の値を所定量増加させると共に前記各解放処理向けのスレッド数を増やし、前記レスポンスタイムが所定基準を満たしていないならば、前記全格納領域のサイズを
所定量拡大することで前記第１格納領域および前記第２格納領域の格納領域サイズを拡大するものである、としてもよい。
【００６６】
これによれば、レスポンスタイムの良否に応じて、ＧＣ処理の高速化か第１格納領域拡大によるオブジェクトの溢れ防止を選択的に実行可能となり、ひいては、Ｇ１ＧＣ方式でのＦｕｌｌＧＣ発生を精度良く回避出来ることになる。
【００６７】
また、本実施形態のメモリ管理装置において、前記演算装置は、前記全解放処理が発生した場合、前記サイズを所定量拡大する処理に先立ち、前記全格納領域のうち、前記第１格納領域および前記第２格納領域のいずれかのオブジェクトのうち所定時間以上にわたり使用中のオブジェクトを格納する第３格納領域での、サイズが所定基準以上のオブジェクトの存在数が所定数を越えるか判定し、当該判定の結果、前記第３格納領域での前記オブジェクトの存在数が所定数を越えない場合に、前記サイズを所定量拡大する処理に移行し、当該判定の結果、前記第３格納領域での前記オブジェクトの存在数が所定数を越える場合に、前記プログラムないしハードウェアの改修を示唆する通知を所定装置に出力する処理を更に実行するものである、としてもよい。
【００６８】
これによれば、第３格納領域すなわちＴｅｎｕｒｅｄ領域におけるＨｕｍｏｎｇｏｓ領域での、大きなサイズ（例：Ｓｕｒｖｉｖｏｒ領域の半分以上のサイズ）のオブジェクトの存在数に応じて、メモリ管理だけで性能要件を達成するのは困難な場合を特定し、状況改善をユーザ等に示唆することが出来る。こうした示唆に応じてプログラムやハードウェアの改修が行われることで、ひいてはＧ１ＧＣ方式でのＦｕｌｌＧＣ発生を精度良く回避し、システムの安定的な稼働を図ることが可能となる。
【００６９】
また、本実施形態のメモリ管理方法において、前記情報処理装置が、前記サイズを所定量拡大する処理に際し、前記第２格納領域の使用率が所定基準以上である場合、前記全格納領域のサイズを所定量拡大することで前記第２格納領域のサイズも拡大するか、または、前記第２格納領域のサイズのみを所定量拡大し、当該拡大の結果、前記第２格納領域のサイズを当該拡大前のサイズより所定割合以上拡大出来なかった場合、前記第１格納領域と前記第２格納領域の一部とを対象とする所定の第２解放処理における前記第２格納領域での解放処理対象の領域を増加させる、としてもよい。
【００７０】
また、本実施形態のメモリ管理方法において、前記情報処理装置が、前記サイズを所定量拡大する処理に際し、前記第２格納領域の使用率が所定基準より小さい場合、前記負荷テストの実行結果のうちレスポンスタイムが所定基準を満たしているか判定し、当該判定の結果、レスポンスタイムが所定基準を満たしているならば、前記各解放処理による前記機能の目標停止時間の値を所定量増加させると共に前記各解放処理向けのスレッド数を増やし、前記レスポンスタイムが所定基準を満たしていないならば、前記全格納領域のサイズを所定量拡大することで前記第１格納領域および前記第２格納領域の格納領域サイズを拡大する、としてもよい。
【００７１】
また、本実施形態のメモリ管理方法において、前記情報処理装置が、前記全解放処理が発生した場合、前記サイズを所定量拡大する処理に先立ち、前記全格納領域のうち、前記第１格納領域および前記第２格納領域のいずれかのオブジェクトのうち所定時間以上にわたり使用中のオブジェクトを格納する第３格納領域での、サイズが所定基準以上のオブジェクトの存在数が所定数を越えるか判定し、当該判定の結果、前記第３格納領域での前記オブジェクトの存在数が所定数を越えない場合に、前記サイズを所定量拡大する処理に移行し、当該判定の結果、前記第３格納領域での前記オブジェクトの存在数が所定数を越える場合に、前記プログラムないしハードウェアの改修を示唆する通知を所定装置に出力する処理を更に実行する、としてもよい。
【符号の説明】
【００７２】
１００  メモリ管理装置
１０１  補助記憶装置
１０３  主記憶装置（メモリ）
１０４  演算装置
１０５  入力装置
１０６  出力装置
１０７  ヒープ領域（全格納領域）
１０７１  Ｎｅｗ領域
１０７１１  Ｅｄｅｎ領域（第１領域）
１０７１２  Ｓｕｒｖｉｖｏｒ領域（第２格納領域）
１０７２  Ｔｅｎｕｒｅｄ領域（第３格納領域）
１０７２１  Ｈｕｍｏｎｇｏｓ領域（第３格納領域）
１０７３  Ｆｒｅｅ領域
１０７４  ＭｅｔａＳｐａｃｅ領域
１０８  オブジェクト管理情報
１１０  Ｊａｖａコンパイラ
１１１  ＪａｖａＶＭ
１１２  Ｊａｖａクラスファイル
１１３  Ｊａｖａソースファイル
１１４  コンフィグファイル
１１５  ＯＳ（オペレーティングシステム）
１１６  性能要件テーブル
１１７  チューニング前試算テーブル
１１８  パラメータ値算出結果テーブル
１１９  チューニング後試算テーブル
【図１】
2017142670.tif 000003
【図２】
2017142670.tif 000004
【図３】
2017142670.tif 000005
【図４】
2017142670.tif 000006
【図５】
2017142670.tif 000007
【図６】
2017142670.tif 000008
【図７】
2017142670.tif 000009
【図８】
2017142670.tif 000010
【図９】
2017142670.tif 000011