JP4170988B2 - 実行環境の危険予測/回避方法,システム,プログラムおよびその記録媒体 - Google Patents
実行環境の危険予測/回避方法,システム,プログラムおよびその記録媒体 Download PDFInfo
- Publication number
- JP4170988B2 JP4170988B2 JP2004571568A JP2004571568A JP4170988B2 JP 4170988 B2 JP4170988 B2 JP 4170988B2 JP 2004571568 A JP2004571568 A JP 2004571568A JP 2004571568 A JP2004571568 A JP 2004571568A JP 4170988 B2 JP4170988 B2 JP 4170988B2
- Authority
- JP
- Japan
- Prior art keywords
- memory
- garbage collection
- risk
- warning
- execution environment
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/023—Free address space management
- G06F12/0253—Garbage collection, i.e. reclamation of unreferenced memory
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99956—File allocation
- Y10S707/99957—Garbage collection
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
- Memory System (AREA)
Description
上記のエンタープライズアプリケーションとしては,主にJava(登録商標)を使用したWebアプリケーションなどがある。
また,上記のエンタープライズアプリケーションの構成には,さらに中間層を2階層に分けた4階層システムもある。
また,上記のサーバ側に配置される中間層の実行環境としては,主にJava仮想マシン(Java Virtual Machine)などがある。
本発明は,Javaのようなガベージコレクションなどのメモリ管理機能をもった実行系を対象としている。
第1図は,Javaアプリケーションの運用環境の例を示す図である。第1図の例では,Javaアプリケーションの実行環境1000におけるアプリケーションの運用時のデータが収集され,そのときに収集されたデータを性能分析ツール2000が分析する。性能分析ツール2000における分析結果をJavaアプリケーションの実行環境1000にフィードバックすることにより,最適なJavaアプリケーションの運用環境を構築している。
Javaアプリケーションの実行環境1000において,OS1010の上位層にJava仮想マシン1020があり,その上位層にアプリケーションサーバ1030がある。アプリケーションサーバ1030の例として,EJB(Enterprise JavaBeans)やServletなどを動かすプログラムであるEJBコンテナやServletコンテナなどがある。アプリケーションサーバ1030の上位層で,Servlet,JSP(Java Server Pages),EJB等のアプリケーション1040が動作する。Webサーバ1050はクライアントからの要求を受け付ける。Javaアプリケーションの運用状況を最もよく知っているのは,実行環境1000の中で最下層に位置して実際にアプリケーションを実行しているJava仮想マシン1020である。
性能分析ツール2000において,実行環境1000から収集されたデータは性能データベース2010に蓄積され,蓄積されたデータは分析プログラム2020によって解析される。分析結果をモニタリングツール2030で表示したり,ドリルダウンツール2040でより細かく分析したりする。また,サービスレベル診断2050により,クライアントからの要求に対してサーバが決められた時間内に応答しているか,現在のサービスの状態が満たされているかなどを診断する。
第2図は,従来のJavaアプリケーションの運用環境の分析方法の例を示す図である。第2図において,Javaアプリケーションを運用するサーバ3000(Javaアプリケーションの実行環境1000を有するサーバ)から収集されたデータは,性能データベース2010を備えるデータ蓄積装置3010に蓄積される。性能分析装置3020は,データ蓄積装置3010に蓄積されたデータを参照し,そのデータを分析プログラム2020によって解析する。運用管理者3030は,性能分析装置3020において,モニタリングツール2030により分析結果をグラフ表示したり,ドリルダウンツール2040により詳細な分析を行ったり,サービスレベル診断2050によりサービスレベルの診断を行う。
エンタープライズアプリケーションの安定運用に関する従来の技術としては,以下のような技術がある。
(第1の従来技術)
サービスの処理性能やサーバ側のシステム性能を運用管理者がモニタリングツールで監視する技術がある。この技術では,測定したデータの分析を行い,しきい値と連携させてトラブルの兆候を予測・検出し,それを運用管理者に通知する。また,測定したデータを分析ツールによって解析することで,運用状況のグラフ化や評価,性能データの詳細な分析(ドリルダウン)を行い,性能低下のボトルネックの特定などを支援する。第2図の例が,この第1の従来技術の例となる。
上記のサービスの処理性能とは,クライアントからの要求に対して何秒間で応答できるかなどである。また,上記のサーバ側のシステム性能とは,CPU使用率,メモリ使用量,ネットワーク使用率などである。
第1の従来の技術が記載された文献には,以下のようなものがある。
Systemwalker,パフォーマンス管理製品,富士通株式会社,(URL:http://systemwalker.fujitsu.com/jp/com/conc/pafo.html) システム管理/Tivoli,パフォーマンス&アベイラビリティ製品,日本IBM株式会社,(URL:http://www−6.ibm.com/jp/software/tivoli/products/index.html#per) Precise/Indepth for J2EE,日揮情報ソフトウェア株式会社,(URL:http://www.jsys−products.com/product/pre_ind_j2ee/document.html)
処理性能が異なるサーバが混在する環境において,サーブレットやEJBなどのサービスの処理時間を測定し,処理の速いサーバを自動選択してクライアントからの要求を振り分けることで,システム全体としての処理を効率的に行う技術がある。
第2の従来の技術が記載された文献には,以下のようなものがある。
IBM eServer,異機種間ワークロード管理,日本IBM株式会社,(URL:http://www−6.ibm.com/jp/servers/eserver/ac/tech/index2_1.html)
Javaのメモリ量を調べるAPI(Application Program Interface)を使ってJava仮想マシンが管理しているメモリ(ヒープ)サイズの定期調査を行い,メモリ不足を検出する技術がある。この技術では,メモリの空きがしきい値より不足した場合に,ガベージコレクションを強制実行することにより,メモリの空きの回復を促している。
第3の従来の技術が記載された文献には,以下のようなものがある。
WebLogic Server,Java仮想マシンのチューニング,自動的な低メモリ状態の検出とガベージコレクションの強制,日本BEAシステムズ株式会社,(URL:http://edocs.beasys.co.jp/e−docs/wls/docs70/perform/JVMTuning.html#489159)
Java仮想マシン・プロファイラインタフェースによりJava仮想マシンで発生したイベントを計測し,実行時間の長いメソッド(ボトルネック)の検出や,メモリリークの危険性のあるオブジェクトの検出,デッドロックの危険性のあるスレッドの検出を行う技術がある。
Java仮想マシン・プロファイラインタフェースにより計測されるイベントには,“ガベージコレクションを開始した/終了した”,“Javaのメソッドに入った/終了した”,“オブジェクトを割り当てた/解放した”,“Javaスレッドの状態が遷移した”などがある。
しかし,以上のようなエンタープライズアプリケーションの安定運用に関する従来の技術には,以下のような問題があった。
(第1の従来技術の問題点)
第1の従来技術では,様々なデータを採取してそれをグラフなどで表示して監視するモニタリングツールは,トラブル予測と回避のステップに人間の介在を必要とするため,タイムリー性と自律性に欠けていた。特に,ドリルダウンツールで分析する方法ではタイムリー性はまったくなかった。また,データの収集,サービスレベル診断(分析),警告の通知までは自動的に行われていても,警告を受けてからの対処は自動化されていないものが多かった。さらに,データをどのくらい収集していつ分析を行うかなどの条件が,危険性の発見のタイミングに影響していた。
(第2の従来技術の問題点)
第2の従来技術では,処理が自動的に行われているが,それはあくまでサービス時間を計測して負荷分散するロードバランスの仕組みであって,収集した様々なデータを分析して危険の要因を発見する技術ではなかった。
(第3の従来技術の問題点)
第3の従来技術では,処理が自動的に行われているが,トラブルを予測するアルゴリズムに問題があった。Java仮想マシンのメモリ(ヒープ)不足はトラブルの主要因ではあるが,空き容量としきい値を比較してヒープ不足を検出するだけでは必ずしも正しい判断ができているとはいえない。
ヒープが不足した場合には,Java仮想マシンは自動的にガベージコレクションを実行してメモリの回復を図るが,上記第3の従来技術では,それより前に強制的なガベージコレクションでメモリの回復を図っている。この技術は,メモリの使用量がしきい値を超えた後に徐々にメモリ使用量が増え,自動的なガベージコレクションが起きるまでに比較的長い時間がかかる場合には,有効かもしれない。
しかし,すべてがこのような状況であるとは限らない。例えば,メモリの絶対量が不足していてガベージコレクションの頻度が高い場合には,強制的にガベージコレクションを起こしてもすぐに次のガベージコレクションが起きてしまい,負荷の高いガベージコレクション処理を何度も行ってしまうことになる。
(第4の従来技術の問題点)
第4の従来技術では,Java仮想マシン・プロファイラインタフェースで提供されているイベントの発行頻度が非常に高く,そのためにJava仮想マシンに余分な負荷をかけてしまっていた。また,あらかじめ決められたインタフェースを使用しているため,危険性の発見に必要な情報がなかったり,できることの自由度が低かったりしていた。CPU使用率の高いシーケンスコール(ボトルネック)やメモリリークを見つけるツールにはプロファイラインタフェースを使ったものが多いが,負荷が比較的に高く,これらはアプリケーションの運用時ではなくテストの段階で行われるべきものであった。
以上の従来技術の問題点を解決し,アプリケーションを安定に運用させてミッションクリティカルなシステムを実現するには,異常が発生する前にトラブルの危険を察知して回避する必要がある。そのためには,危険性を発見してから回避するまでに,以下の条件を満たす必要がある。
(1)トラブルを予測するためのデータ採取の負荷を軽くし,アプリケーションの運用に負荷を与えない。
(2)トラブルを予測する判断材料とアルゴリズムには適切なものを用い,より正確な予測を行う。
(3)データの測定からトラブルを予測,通知,回避するまでの処理を,短時間かつタイムリーに行う。さらに,これらのステップは,すべて自動的(自律的)に行われることが望ましい。
本発明は,このような状況に鑑みてなされたものであり,データ採取の負荷を軽くし,適切な判断材料とアルゴリズムとからより正確な危険性の予測を行い,データの測定からトラブルの予測,通知,回避までの処理を,短時間かつタイムリーに行い,それらの処理を自動的に実行することが可能となる技術を提供することを目的とする。
具体的には,例えば,エンタープライズアプリケーションの中間層の実行環境としてJava仮想マシンを例とした場合,ガベージコレクションのイベント発生時にその発生時刻やメモリ使用量などのデータを測定し,それ以外は定期的にメモリの使用量などを計測する。測定されたデータをもとに,メモリ不足エラー(以下,OutOfMemoryという)の危険性やメモリ不足による性能低下などを予測し,それらの警告を通知する。また,危険性を回避するために必要なメモリ量を計算する。メモリ不足の危険性の予測には,基本的なガベージコレクションに合わせた予測だけではなく,世代型ガベージコレクションなどの特殊なガベージコレクションに合わせた予測も行う。
本発明による実行環境の危険予測/回避方法によれば,ガベージコレクション以外のイベント発生時(例えば,メモリの割り当てのイベント発生時など)にはメモリ使用量などの測定を行わず,主にガベージコレクションのイベント発生時の測定と,必要に応じて比較的長い周期での定期的な測定によって,メモリ使用量などの測定を行うため,アプリケーションの運用に負荷をかけずにデータの測定を行うことができる。また,本発明による実行環境の危険予測/回避方法によれば,予測されたメモリ不足の危険性を回避するために必要なメモリ量を計算し,その計算されたメモリ量を通知するため,アプリケーションの実行環境の状態回復を早く,容易に行うことができる。また,本発明による実行環境の危険予測/回避方法によれば,ガベージコレクションの種類ごとに対応するアルゴリズムによって危険性の判断を行うため,より正確な危険性の判断を行うことができる。
以上のような本発明による実行環境の危険予測/回避方法は,コンピュータとソフトウェアプログラムとによって実現することができ,そのプログラムをコンピュータ読み取り可能な記録媒体に記録することも,ネットワークを通して提供することも可能である。このプログラムは,ハードディスク等の媒体にインストールされ,主記憶装置に展開されてCPUによって実行される。また,記録媒体としては,CD−ROMやDVD等の可搬型記録媒体が考えられる。
第2図は,従来のJavaアプリケーションの運用環境の分析方法の例を示す図である。
第3図は,危険予測/回避システムの構成例を示す図である。
第4図は,設定データの例を示す図である。
第5図は,測定・分析手段を説明する図である。
第6図は,ガベージコレクションの発生間隔とメモリ使用量に関する代表的な3つの状態を示す図である。
第7図は,警告を行うべき状態を説明する図である。
第8図は,世代型ガベージコレクションにおけるガベージコレクションの発生間隔とメモリ使用量に関する状態を説明する図である。
第9図は,溢れ量の測定を説明する図である。
第10図は,ダイナミックにサイズを変更する世代型ガベージコレクションにおけるガベージコレクションの発生間隔とメモリ使用量に関する状態を説明する図である。
第11図ないし第15図は,メモリ使用量測定・分析処理フローチャートである。
第16図および第17図は,メモリ使用量測定・分析手段の警告対象となる状態の例を示す図である。
第18図は,スレッド測定・分析処理フローチャートである。
第19図は,Java仮想マシンとアプリケーションサーバとの連携によるJava仮想マシンへの処理の振り分けを示す図である。
第20図は,Java仮想マシンとアプリケーションサーバとの連携を示す図である。
第21図は,分析結果通知処理フローチャートである。
第22図は,コマンド通知処理フローチャートである。
第23図は,Java仮想マシン最適制御処理フローチャートである。
Java仮想マシン1は,測定・分析手段10を備える。また,測定・分析手段10は,メモリ使用量測定・分析手段11と,スレッド測定・分析手段12と,設定データ100とを備える。
アプリケーションサーバ2は,Java仮想マシン制御手段20を備える。また,そのJava仮想マシン制御手段20は,Java仮想マシン最適制御手段21を備える。
Java仮想マシン連携手段3は,分析結果通知手段31と,コマンド通知手段32とを備える。
第4図は,設定データの例を示す図である。測定・分析手段10が備える設定データ100は,第4図に示すように,メモリ使用量測定フラグ101,スレッド測定フラグ102,GC発生間隔警告しきい値(th1)103,OutOfMemory警告しきい値A(th2)104,OutOfMemory警告しきい値B(th3)105,メモリ不足警告しきい値(th4)106,メモリ空き回復しきい値(th5)107,new世代不足警告しきい値(th6)108,溢れ量警告しきい値(th7)109,デッドロック警告しきい値(th8)110のデータである。なお,上記GCはガベージコレクションを意味する。以下,場合によってガベージコレクションをGCと記載する。
設定データ100におけるこれらの値は,アプリケーションサーバ2がコマンドを発行して設定することができる。また,事前にまたは随時,図示省略した設定用プログラムを用いてシステム管理者等が設定することもできる。
以下,各手段の動作を説明するが,最初に,Java仮想マシン1内でデータの測定と分析,危険性の予測を行う部分について説明し,次に,分析結果をアプリケーションサーバ2に通知して最適な運用環境になるようにフィードバックする部分について説明する。
本発明では,第3図に示すように,Java仮想マシン1がその内部に測定・分析手段10を備える。データの測定・分析,トラブル発生の予測は,Java仮想マシン1の内部で行われる。よって,本発明では,測定データをデータベースなどに一度出力して分析プログラムによって判断するような第1の従来技術に比べて,データの測定から分析,トラブルの予測までをタイムリーに行うことができる。
第5図は,測定・分析手段を説明する図である。Java仮想マシン1内の測定・分析手段10は,定期的に(例えば,数秒間隔に)データを計測する機能10αと,ガベージコレクションのイベント発生時にデータを計測する機能10βとの2つのデータ測定機能を持っている。
Java仮想マシン1で使用されているメモリ(ヒープ)の量は,“メモリの割り当て/解放”のイベント発生時に測定されたものが正確な量である。しかし,イベントの発生頻度は非常に高く,すべてのイベント発生時にデータを測定するとアプリケーションの運用に負荷がかかってしまう。メモリ使用量の分析と危険性の予測は,定期的に取得するデータで行うことが可能であり,“メモリの割り当て/解放”イベント発生時にデータの測定を行う必要はない。
測定・分析手段10は,アプリケーションの運用に負荷をかけずに正確にデータを測定できるように,測定する項目に応じて2つのデータ測定機能(10α,10β)から使用するデータ測定機能を選択する。
第3図に示すように,Java仮想マシン1内の測定・分析手段10は,メモリ使用量の測定と分析を行うメモリ使用量測定・分析手段11と,Javaスレッドの測定と分析を行うスレッド測定・分析手段12とを備える。
まず,メモリ使用量測定・分析手段11について説明する。メモリ使用量測定・分析手段11は,Java仮想マシン内1で,使用メモリ(ヒープ)量の定期的な測定とガベージコレクション発生時の測定とを行い,それらの測定で得られたデータを分析する。分析の結果,メモリ量が不足していてOutOfMemoryのエラーが発生する危険性がある場合や,メモリ不足が性能に悪影響を及ぼしている場合などには,そのことへの警告を行う。また,そのときの状態の回復に必要なメモリサイズを見積もる。
メモリ使用量測定・分析手段11は,Java仮想マシン1が使用中のメモリ量を,定期的な間隔で測定する。このときの測定間隔は,Java仮想マシン1を起動するときのオプションや,アプリケーションサーバ2内のJava仮想マシン制御手段20(詳細は後述)からのコマンドにより,設定/変更可能である。また,メモリ使用量測定・分析手段11は,ガベージコレクションのイベント発生時に,データを測定する。
Java仮想マシン1は,自分自身の動作状況をよく知っているため,自身内でトラブルの危険性を検出することができる。Java仮想マシン1内でのトラブルで一番深刻なものは,メモリ(ヒープ)不足である。このメモリ不足によってマシン性能が低下し,ひどい場合には処理が止まってしまうこともある。
また,クライアントからのトランザクションの要求量が予想以上に多くなることがあり,メモリ使用量が当初の見積もりよりもオーバーしてしまうことがある。クライアントからの要求量は刻々と変化するものであり,メモリ使用量も状況に応じて変化するものである。このような場合,前述の第3の従来技術のように測定した使用メモリ量としきい値とを単純に比較するだけでは,メモリ不足の危険性を正確に判断することはできない。よって,状況に応じたもっと適切な判断をする必要がある。
Javaのアプリケーションでは,メモリが必要なときに,new演算子でメモリの獲得が行われる。しかし,Javaのアプリケーションではメモリの解放をプログラムに書くことはできず,メモリの解放はJava仮想マシン1に任されている。Java仮想マシン1におけるメモリの解放処理,すなわちガベージコレクションは,マシン性能に対して非常に大きな影響を与える。そのため,状況に合わせた様々な方式のガベージコレクションが研究されており,それぞれのJava仮想マシン1によって採用しているガベージコレクションの方式は異なる。
よって,メモリ不足の危険性を判断する方法は,すべてのガベージコレクションに適用できる共通の判定方法に加えて,Java仮想マシン1ごとに採用されているガベージコレクションに固有の判定方法が必要となる。
メモリ使用量測定・分析手段11は,測定されたデータを分析し,すべてのガベージコレクションに適用できる共通のメモリ不足の危険性の判断と,各Java仮想マシン1ごとに採用されたガベージコレクションに固有のメモリ不足の危険性の判断とを行う。また,それぞれの判断結果から,危険な状態に対する警告,状態の回復に必要なメモリ量の計算を行う。
メモリ使用量測定・分析手段11による基本的なデータの分析,危険な状態に対する警告,状態の回復に必要なメモリ量の計算について説明する。まず,ガベージコレクションの発生間隔とメモリ使用量に関する代表的な3つの状態について,図を用いて説明する。
第6図は,ガベージコレクションの発生間隔とメモリ使用量に関する代表的な3つの状態を示す図である。第6図(A)〜(C)に示すグラフは,メモリ使用量200の変化とガベージコレクション210の発生をグラフ化して表したものの例であり,ガベージコレクション210の発生間隔とメモリ使用量200に関する代表的な3つの状態を示している。
第6図(A)〜(C)のグラフでは,縦軸にメモリ量をとっており,横軸に時間をとっている。第6図(A)〜(C)において,実線はメモリ使用量200の時間変化を示し,点線は設定されている最大ヒープサイズ220を示す。Java仮想マシン1は,“メモリの割り当て”イベントによりメモリ使用量200が最大ヒープサイズ220を超えそうなときに,ガベージコレクション210を実行し,メモリの解放を行う。
第6図(A)は,ガベージコレクション210が発生しない安定した状態,あるいは,ガベージコレクション210の発生間隔が比較的長く,ガベージコレクション210によってメモリの空きが回復する状態を表している。第6図(B)は,ガベージコレクション210の発生間隔が短くなる傾向にあるが,ガベージコレクション210によってメモリの空きが回復する状態を表している。第6図(C)は,ガベージコレクション210の発生間隔が短く,ガベージコレクション210によってメモリの空きが十分に回復しない状態を表している。第6図(B)の状態,第6図(C)の状態が,警告の対象となる。
第7図は,警告を行うべき状態を説明する図である。
第7図(A)は,メモリ不足による性能低下の警告を行うべき状態を示している。第7図(A)では,縦軸にガベージコレクションの発生間隔をとっており,横軸にガベージコレクションの発生を順に等間隔にとっている。この例では,ガベージコレクションの発生間隔が,GC発生間隔警告しきい値103を下回って推移している。
第7図(B),(C)は,OutOfMemoryの危険性の警告を行うべき状態を示す図である。第7図(B),(C)では,縦軸にメモリ量をとっており,横軸に時間をとっている。第7図(B)において,太線104’は(全容量×OutOfMemory警告しきい値A104)で求められた値である。また,第7図(C)において,太線105’は(全容量×OutOfMemory警告しきい値B105)で求められた値である。
第7図(B)において,メモリ使用量200の変化を見ると,GC210によってメモリの空きがほとんど回復していない。GC210後のメモリ使用量200が太線104’を上回っていることから,メモリの使用率(メモリ使用量/全容量)がOutOfMemory警告しきい値A104を上回っていることがわかる。
第7図(C)において,メモリ使用量200の変化を見ると,GC210a,GC210b,GC210cと順に徐々にメモリの空きが回復しなくなってきていることがわかる。また,GC210b後,GC210c後のメモリ使用量200が太線105’を上回っていることから,GC210b後,GC210c後のメモリの使用率がOutOfMemory警告しきい値B105を上回っていることがわかる。
ここで,OutOfMemory警告しきい値A104は,OutOfMemory警告しきい値B105より大きい値であるものとする。メモリの使用率がOutOfMemory警告しきい値A104を下回っていても,メモリの使用率がOutOfMemory警告しきい値B105を上回って増加傾向にあれば,OutOfMemoryの危険性があると判断される。
以下の(判断1)〜(判断3)は,メモリ使用量測定・分析手段11による基本的なガベージコレクションのメモリ不足の危険性の判断ロジックを示している。なお,以下の基本的なガベージコレクションの判断において,使用率とはメモリの全容量に対するメモリ使用量の割合を示す。よって,以下の式(1)のとおりとなる。
使用率=メモリ使用量/全容量 ・・・式(1)
(判断1)ガベージコレクションの発生間隔を測定し,その発生間隔がGC発生間隔警告しきい値103を下回る状態が続いている場合には,メモリ不足で性能が低下していると判断する(第7図(A)参照)。
(判断2)ガベージコレクション後のメモリ使用量を測定し,使用率がOutOfMemory警告しきい値A104を上回っている場合には,OutOfMemoryの危険性があると判断する(第7図(B)参照)。
(判断3)ガベージコレクション後のメモリ使用量を測定し,使用率が連続して増加傾向にあり,それらがOutOfMemory警告しきい値B105を上回っている場合には,OutOfMemoryの危険性があると判断する(第7図(C)参照)。
メモリ使用量測定・分析手段11は,(判断1)〜(判断3)に示すような基本的なガベージコレクションの危険性の判断結果をもとに,OutOfMemoryの危険性の警告,メモリ不足による性能低下の警告などを行う。
また,メモリ使用量測定・分析手段11は,状態の回復に必要なメモリ量の計算を行う。例えば,(判断1)〜(判断3)における回復に必要なメモリサイズは,ガベージコレクション後のメモリの空き率(空き率=1−使用率)がメモリ空き回復しきい値107を超えるように計算されたサイズとする。計算は,以下の式(2)を満たすm(回復のために追加する容量)を求める計算となる。
(空き容量+m)/(全容量+m)
>メモリ空き回復しきい値107 ・・・式(2)
以上,メモリ使用量測定・分析手段11による基本的なデータの分析,危険な状態に対する警告,状態の回復に必要なメモリ量の計算について説明した。さらに各ガベージコレクションの特徴に合わせて判断の追加・改良を行うことにより,より正確なデータの分析,危険な状態に対する警告,状態の回復に必要なメモリ量の計算を行うことができる。
次に,メモリ使用量測定・分析手段11による世代型ガベージコレクションの特徴に合わせたデータの分析,危険な状態に対する警告,状態の回復に必要なメモリ量の計算について説明する。
世代型のガベージコレクションは,メモリ(ヒープ)を新世代,旧世代の2つの領域に分けて管理している。Javaプログラムのオブジェクトがメモリに割り当てられるときには,まず新世代のメモリに割り当てられる。新世代のメモリがいっぱいになると,新世代のガベージコレクション(以下,newGCという)が発生する。newGCを何度か経験して残ったオブジェクトは,旧世代のメモリに移動される。旧世代のメモリがいっぱいになるとメモリ全体のガベージコレクション(以下,単にガベージコレクションまたはGCという)が発生する。したがって,新世代のメモリ使用量は変化が非常に激しいものとなる。
前述の第3の従来技術に示したJavaのAPIに,全体のメモリ量と空きのメモリ量を求めるAPIがある。しかし,これらのAPIが新世代と旧世代を合わせた合計のメモリ量をデータとして返すような場合には,そのデータをグラフにしても第6図に示すようなグラフにはならない。よって,データを正しく分析することができない。世代型ガベージコレクションの場合には,新世代と旧世代のメモリ使用量を別々に測定してデータを分析する必要がある。
第8図は,世代型ガベージコレクションにおけるガベージコレクションの発生間隔とメモリ使用量に関する状態を説明する図である。第8図(A)〜(C)に示すグラフは,旧世代,新世代別にメモリ使用量(旧世代201,新世代202)の変化とガベージコレクション(GC)210,newGC211の発生をグラフにしたものの例であり,ガベージコレクション210,newGC211の発生間隔とメモリ使用量(201,202)に関する代表的な3つの状態を表している。
第8図(A)〜(C)のグラフでは,縦軸にメモリ量をとっており,横軸に時間をとっている。第8図(A)〜(C)において,点線は設定されている最大ヒープサイズ220を示し,一点鎖線は新世代と旧世代のメモリの領域の境界221を示す。一点鎖線から下の領域が旧世代のメモリの領域となり,一点鎖線から点線(最大ヒープサイズ220)までの領域が新世代のメモリの領域となる。各世代における実線は,各世代別のメモリ使用量(201,202)の時間変化を示す。なお,第8図(A)〜(C)のそれぞれの状態は,第6図(A)〜(C)のそれぞれの状態に対応する。
Java仮想マシン1は,メモリの割り当てイベントにより新世代のメモリ使用量202が新世代のメモリ量を超えるとき(第8図では最大ヒープサイズ220を超えるとき)に,newGC211を実行し,新世代のメモリの解放を行う。また,Java仮想マシン1は,newGC211を何度か経験して新世代のメモリに残っているオブジェクトを旧世代のメモリに移し,旧世代のメモリがいっぱいで新世代のメモリからオブジェクトを移せなくなるときに,メモリ全体のガベージコレクション210を実行する。
newGC211の発生頻度はメモリ全体のGC210の発生頻度より高い。しかし,GC210の処理時間が数秒,場合によっては十数秒であるのに対し,newGC211の処理時間は数十ミリ秒程度である。レスポンス時間が重要なアプリケーションでは,できるだけGC210が発生しない状態(第8図(A)の状態)を維持するようにする必要がある。
GC210が発生するのは,新世代から旧世代に移動するオブジェクトが多い場合であり,長寿命なオブジェクトが多いケースと,新世代のメモリサイズが小さくて溢れが発生するケース(世代が若くても旧世代に移動させる(溢れ)アルゴリズムを採用している場合など)とがある。newGC211時に,新世代のメモリから旧世代のメモリに溢れるオブジェクトのサイズ(以下,溢れ量という)を測定することで,第8図(B)や第8図(C)の状態を第8図(A)の状態にするのに必要なメモリ量を見積もることができる。
第9図は,溢れ量の測定を説明する図である。第9図(A)は,newGC211で新世代240のメモリから旧世代230のメモリにオブジェクトが溢れる状態を示しており,ハッチング部分が溢れ量である。ここで,newGC211が起きた時刻に新世代240のメモリ量が十分にあった(newGC211の発生するタイミングが伸びた)ものと仮定し,そのときの状態を第9図(B)のように表現するものとする。これをnewGC211のたびに繰り返すと第9図(C)のような状態になる。
第9図(C)は,実際には4回のnewGC211で溢れたオブジェクトが,新世代240のメモリ量が無限に存在し,溢れなかったものと仮定した状態を示している。k回目の溢れ量をtkと表すとすると,第9図(C)の時点で溢れなかったと仮定された溢れ量の合計は,t1+t2+t3+t4となる。もし,新世代240の領域に最初から元の量のメモリに加えてt1+t2+t3+t4の量のメモリが余計にあったなら,4回のnewGC211までで新世代240のメモリから溢れるオブジェクトはない。
さらに,時間が経つにつれて不要となるオブジェクトがあるので,それを考慮して溢れ量を見積もると以下のようになる。例えば,第9図(C)において,1回目のnewGC211で溢れたオブジェクトが溢れずに4回目のnewGC211の時間まで新世代240の領域に残っているものとすると,その一部は不要なオブジェクトになっているはずである。同様に,2回目のnewGC211時に溢れたオブジェクト,3回目のnewGC211時に溢れたオブジェクトの中にも,4回目のnewGC211の時間までに不要となるオブジェクトが存在する。第9図(C)において,4回目のnewGC211までに溢れなかったものとされたオブジェクトの一部は,4回目のnewGC211までに解放されてもよいはずである。実際には,第9図(C)は,第9図(D)のような状態であると考えられる。
第9図(D)において,1回のnewGC211によるオブジェクトの生存率をd,k回目の溢れ量をxkと表すとすると,
x1=t1×d3
x2=t2×d2
x3=t3×d1
x4=t4×d0
となり,溢れ量の累計は,x1+x2+x3+x4となる。よって,新世代240のメモリ量がx1+x2+x3+x4だけ余分にあれば,溢れを起こさなかったこととなる。
一般的に,n回のnewGCの溢れ量の累計は,以下の式(3)で求められる。式(3)において,xtotalは溢れ量の累計を示す。
xtotal=Σk=1 n(tk×dn−k) ・・・式(3)
以下,メモリ使用量測定・分析手段11による世代型ガベージコレクションの特徴に合わせたメモリ不足の危険性の判断ロジックを示す。世代型ガベージコレクションにおけるメモリ不足の危険性の判断は,前述の(判断1)〜(判断3)に,以下の(判断4)と(判断5)とを加えたものとなる。
なお,以下の世代型ガベージコレクションの判断において,メモリ使用率の計算には,式(1)の代わりに以下の式(4)を用いるものとする。
使用率=旧世代メモリ使用量/旧世代容量 ・・・式(4)
(判断4)ガベージコレクション後のメモリ使用量を測定し,メモリの使用率がメモリ不足警告しきい値106を下回っていても(十分にメモリの空きが回復していても),GCの発生間隔がGC発生間隔警告しきい値103を下回っており,新世代のメモリ量の割合(新世代容量/全容量)がnew世代不足警告しきい値108を下回っている場合には,新世代のメモリサイズが小さすぎることが性能に影響している(GCの発生頻度を高くしている)と判断する。
(判断5)式(3)により溢れ量の累計を毎newGC後に計算し,(溢れ量の累計/旧世代空き容量)が溢れ量警告しきい値109を超える場合には,OutOfMemoryの危険性があると判断する。
メモリ使用量測定・分析手段11は,(判断1)〜(判断3)に示した基本的な判断結果と(判断4),(判断5)に示した世代型ガベージコレクションの特徴に合わせた危険性の判断結果とをもとに,OutOfMemoryの危険性の警告,メモリ不足による性能低下の危険性の警告などを行う。
また,メモリ使用量測定・分析手段11は,状態の回復に必要なメモリ量の計算を行う。例えば,(判断1)〜(判断3)における回復に必要なメモリサイズは,ガベージコレクション後のメモリの空き率(空き率=1−使用率)がメモリ空き回復しきい値107を超えるように計算されたサイズとする。計算は,以下の式(5)を満たすm(回復のために追加する容量)を求める計算となる。
(旧世代空き容量+m)/(旧世代容量+m)
>メモリ空き回復しきい値107 ・・・式(5)
また,例えば,(判断5)の場合において,回復に必要な追加メモリ量は,あるGCとその次のGCとの間に発生したnewGCに対して,式(3)により求められた溢れ量の累計とする。
第8図に示すような世代型ガベージコレクションにおける新世代のメモリの領域と旧世代のメモリの領域との割合を,Java仮想マシン1を起動するときのオプションで設定できるものがある。また,第8図に示すような世代型ガベージコレクションでは新世代のメモリサイズと旧世代のメモリサイズとを一定にしているが,新世代のメモリサイズと旧世代のメモリサイズとをダイナミックに変更する世代型ガベージコレクションもある。
第10図は,ダイナミックにサイズを変更する世代型ガベージコレクションにおけるガベージコレクションの発生間隔とメモリ使用量に関する状態を説明する図である。第10図に示すダイナミックにサイズを変更する世代型ガベージコレクションでは,ガベージコレクション210直後のメモリの空き容量を,あらかじめ設定された割合で,新世代のメモリの領域と旧世代のメモリの領域とに分配する。
第10図(A)〜(C)は,旧世代,新世代別に,メモリ使用量(旧世代201,新世代202)の変化とガベージコレクション210,newGC211の発生とをグラフ化して表した例であり,ガベージコレクション210,newGC211の発生間隔とメモリ使用量とに関する代表的な3つの状態を表している。
第10図(A)〜(C)のグラフでは,縦軸にメモリ量をとっており,横軸に時間をとっている。第10図(A)〜(C)において,点線は設定されている最大ヒープサイズ220を示し,一点鎖線は新世代と旧世代のメモリの領域の境界221を示す。一点鎖線から下の領域が旧世代のメモリの領域となり,一点鎖線から点線(最大ヒープサイズ220)までの領域が新世代のメモリの領域となる。各世代における実線は,各世代別のメモリ使用量(201,202)の時間変化を示す。なお,第10図(A)〜(C)のそれぞれの状態は,第6図(A)〜(C)のそれぞれの状態に対応する。
Java仮想マシン1は,メモリの割り当てイベントにより新世代のメモリ使用量202が新世代のメモリ量を超えるとき(第10図では最大ヒープサイズ220を超えるとき)に,newGC211を実行し,新世代のメモリの解放を行う。また,Java仮想マシン1は,newGC211を何度か経験して新世代のメモリに残っているオブジェクトを旧世代のメモリに移す。オブジェクトを新世代のメモリから旧世代のメモリに移した分だけ新世代のメモリが少なくなり,旧世代のメモリが増える。
Java仮想マシン1は,旧世代のメモリがいっぱいになったときに,メモリ全体のガベージコレクション210を実行する。このとき,あらかじめ設定された割合で,ガベージコレクション210直後のメモリの空き容量を,新世代のメモリの領域と旧世代のメモリの領域とに分配する。
メモリ使用量測定・分析手段11によるダイナミックにサイズを変更する世代型ガベージコレクションにおけるメモリ不足の危険性の判断は,前述の(判断1)〜(判断3),(判断5)となる。また,ダイナミックにサイズを変更する世代型ガベージコレクションにおいて,使用率の計算には式(1)を用いる。
メモリ使用量測定・分析手段11は,(判断1)〜(判断3),(判断5)に示す危険性の判断結果をもとに,OutOfMemoryの危険性の警告,メモリ不足による性能低下の警告などを行う。
また,メモリ使用量測定・分析手段11は,状態の回復に必要なメモリ量の計算を行う。ダイナミックにサイズを変更する世代型ガベージコレクションにおいて,回復に必要なメモリ量の計算は,先に示した式(2)を改良する。例えば,(判断1)〜(判断3)の場合における回復に必要なメモリサイズは,ガベージコレクション後の全容量に対する旧世代空き容量の割合がメモリ空き回復しきい値107を超えるように計算されたサイズとする。計算は,以下の式(6)を満たすm(回復のために追加する容量)を求める計算となる。
(旧世代空き容量+旧世代分配率×m)/(全容量+m)
>メモリ空き回復しきい値107 ・・・式(6)
また,(判断5)の場合における回復に必要な追加メモリ量は,前述の世代型ガベージコレクションの場合と同じである。
メモリ使用量測定・分析手段11における処理の例について,第11図から第15図のフローチャートを用いて説明する。
第11図から第15図のフローチャートにおいて,“非ダイナミック世代型GC”は,新世代,旧世代のメモリサイズをダイナミックには変更しない世代型ガベージコレクションを示すものとする。また,“ダイナミック世代型GC”は,ダイナミックにサイズを変更する世代型ガベージコレクションを示すものとする。また,“GC”はメモリ全体のガベージコレクションを示し,“newGC”は世代型GCにおける新世代のガベージコレクションを示す。
第11図は,メモリ使用量測定・分析処理フローチャートである。
まず,メモリ使用量測定フラグ101がONであるか否かを判定し(ステップS1),ONでなければ(OFFであれば)処理を終了する。
ステップS1においてONであれば,GCが発生したか否かを判定し(ステップS2),GCが発生していなければステップS6に進む。
ステップS2においてGCが発生していれば,第12図に示すデータ測定・計算処理を行い(ステップS3),第13図に示すデータ分析・警告処理Aを行い(ステップS4),次いで第14図に示すデータ分析・警告処理Bを行い(ステップS5),ステップS6に進む。
世代型GCであるか否かを判定し(ステップS6),世代型GCでなければ処理を終了する。
ステップS6において世代型GCであれば,第15図に示す世代型GC固有測定・分析処理を行い(ステップS7),処理を終了する。
第12図は,データ測定・計算処理フローチャートである。
まず,今回のGC発生時刻を測定し(ステップS10),今回のGC発生間隔(今回のGC発生時刻−前回のGC発生時刻)を計算する(ステップS11)。次に,GC直後のメモリ使用量と空き容量とを測定し(ステップS12),GC直後のメモリの使用率と空き率(空き率=1−使用率)とを計算し(ステップS13),処理を終了する。
ここで,ステップS12において,世代型GCの場合には,メモリ全体だけではなく,旧世代のメモリについても測定を行う。また,ステップS13のメモリの使用率の計算において,世代型GCでない場合とダイナミック世代型GCである場合には式(1)を用いて計算を行い,非ダイナミック世代型GCである場合には式(4)を用いて計算を行う。
第13図は,データ分析・警告処理Aフローチャートである。
まず“今回の使用率≧th2(OutOfMemory警告しきい値A104)”が成立するか否かを判定し(ステップS20),成立すればステップS26に進む。
ステップS20において成立しなければ,“今回の使用率>前回の使用率”が成立するか否かを判定し(ステップS21),成立しなければ,メモリの使用率の増加が何回連続したかを数えるためのカウンタc1を0とし(ステップS23),処理を終了する。
ステップS21において成立すれば,“今回の使用率>th3(OutOfMemory警告しきい値B105)”が成立するか否かを判定し(ステップS22),成立しなければ,メモリの使用率の増加が何回連続したかを数えるためのカウンタc1を0とし(ステップS23),処理を終了する。
ステップS22において成立すれば,カウンタc1を1インクリメント(c1=c1+1)する(ステップS24)。
カウンタc1があらかじめ任意に設定された値n1以上であるか否かを判定し(ステップS25),値n1以上であればステップS26に進む。ステップS25において値n1以上でなければ,処理を終了する。
ステップS26では,OutOfMemoryの危険性の警告(警告w1)を行い,回復に必要なメモリ量を計算し(ステップS27),処理を終了する。
このステップS27における回復に必要なメモリ量の計算において,世代型GCでない場合には前記式(2)を満たすm(回復のために追加する容量)を求める計算を行い,非ダイナミック世代型GCである場合には前記式(5)を満たすm(回復のために追加する容量)を求める計算を行い,ダイナミック世代型GCである場合には前記式(6)を満たすm(回復のために追加する容量)を求める計算を行う。
第14図は,データ分析・警告処理Bフローチャートである。
まず“今回のGC発生間隔<th1(GC発生間隔警告しきい値103)”が成立するか否かを判定し(ステップS30),成立しなければ,GC発生間隔が何回連続でGC発生間隔警告しきい値103を下回ったかを数えるカウンタc2を0とし(ステップS31),処理を終了する。
ステップS30において成立すれば,カウンタc2を1インクリメント(c2=c2+1)する(ステップS32)。
カウンタc2があらかじめ任意に設定された値n2以上であるか否かを判定し(ステップS33),値n2以上でなければ処理を終了する。
ステップS33において,c2が値n2以上であれば,“今回の使用率≧th4(メモリ不足警告しきい値106)”が成立するか否かを判定し(ステップS34),成立すれば,メモリ不足による性能低下の警告(警告w2)を行い(ステップS35),回復に必要なメモリ量を計算し(ステップS36),処理を終了する。
このステップS36における回復に必要なメモリ量の計算において,世代型GCでない場合には前記式(2)を満たすm(回復のために追加する容量)を求める計算を行い,非ダイナミック世代型GCである場合には前記式(5)を満たすm(回復のために追加する容量)を求める計算を行い,ダイナミック世代型GCである場合には前記式(6)を満たすm(回復のために追加する容量)を求める計算を行う。
ステップS34において成立しなければ,“空き率≧th5(メモリ空き回復しきい値107)”であるか否かを判定し(ステップS37),成立しなければ,GCが短い間隔で発生しているとの警告(警告w3)を行い(ステップS38),処理を終了する。
ステップS37において成立すれば,非ダイナミック世代型GCであるか否かを判定し(ステップS39),非ダイナミック世代型GCでなければ,メモリの消費スピードに比べてメモリの絶対量が小さいなどの警告(警告w4)を行い(ステップS40),処理を終了する。
ステップS39において非ダイナミック世代型GCであれば,“新世代容量/全容量<th6(new世代不足警告しきい値108)”が成立するか否かを判定し(ステップS41),成立すれば新世代の割合が小さいとの警告(警告w5)を行い(ステップS42),処理を終了する。
ステップS41において成立しなければ,メモリの消費スピードに比べてメモリの絶対量が小さい,Survivor容量の割合が小さいなどの警告(警告w6)を行い(ステップS43),処理を終了する。
第15図は,世代型GC固有測定・分析処理フローチャートである。
まず,newGCが発生したか否かを判定し(ステップS50),発生していなければ処理を終了する。
ステップS50においてnewGCが発生していれば,GC後の最初のnewGCか否かを判定し(ステップS51),最初のnewGCでなければステップS53に進む。ステップS51において最初のnewGCであれば,値nを1とし(ステップS52),ステップS53に進む。
newGCで新世代から旧世代に溢れたオブジェクトの量を測定し(ステップS53),式(3)を用いて溢れ量の累計を計算する(ステップS54)。
次に,“溢れ量の累計/旧世代空き容量>th7(溢れ量警告しきい値109)”が成立するか否かを判定し(ステップS55),成立しなければステップS58に進む。
ステップS55において成立すれば,OutOfMemoryの危険性の警告(警告w1)を行い(ステップS56),ステップS54で計算された溢れ量の累計を回復のために追加するメモリ量とし(ステップS57),ステップS58に進む。
値nを1インクリメント(n=n+1)し(ステップS58),処理を終了する。
第16図は,メモリ使用量測定・分析手段の警告対象となる状態の例(1)を示す図である。第16図(A),(B)は,それぞれが第13図の各判断条件に対応している。また,第16図(A),(B)のグラフでは,縦軸にメモリ量をとっており,横軸に時間をとっている。
第16図(A)において,太線104’は(全容量×OutOfMemory警告しきい値A104)で求められた値である。また,第16図(B)において,太線105’は(全容量×OutOfMemory警告しきい値B105)で求められた値である。また,第16図(A),(B)において,太線107’は(全容量×(1−メモリ空き回復しきい値107))で求められた値である。
第16図(A)は,第13図のステップS20が成立する場合の例である。第16図(A)において,メモリ使用量200の変化を見ると,GC210によってメモリの空きがほとんど回復していない。GC210後のメモリ使用量200が太線104’を上回っていることから,メモリの使用率がOutOfMemory警告しきい値A104を上回っていることがわかる。OutOfMemory警告しきい値A104は,例えば,90%〜95%程度である。
第16図(B)は,第13図のステップS21,ステップS22,ステップS25が同時に成立する場合の例である。第16図(B)において,メモリ使用量200の変化を見ると,GC210α,GC210β,GC210γと順に徐々にメモリの空きが回復しなくなってきていることがわかる。また,GC210β後,GC210γ後のメモリ使用量200が連続して太線105’を上回っていることから,GC210β後,GC210γ後のそれぞれのメモリの使用率がOutOfMemory警告しきい値B105を上回っていることがわかる。
第17図は,メモリ使用量測定・分析手段の警告対象となる状態の例(2)を示す図である。第17図(A)〜(C)は,それぞれが第14図の各判断条件に対応している。また,第17図(A)〜(C)のグラフでは,縦軸にメモリ量をとっており,横軸に時間をとっている。
第17図(A)において,太線106’は(全容量×メモリ不足警告しきい値106)で求められた値である。また,第17図(C)において,太線108’は(全容量×(1−new世代不足警告しきい値108))で求められた値である。また,第17図(A)〜(C)において,太線107’は(全容量×(1−メモリ空き回復しきい値107))で求められた値である。
第17図(A)は,第14図のステップS34が成立する場合の例である。第17図(A)において,メモリ使用量200の変化を見ると,GC210によってメモリの空きはある程度回復するが,GC発生間隔が短くなっている。GC210後のメモリ使用量200が太線106’を上回っていることから,メモリの使用率がメモリ不足警告しきい値106を上回っていることがわかる。メモリ不足警告しきい値106は,例えば,80%〜90%程度である。
第17図(B)は,第14図のステップS37が成立する場合の例であり,世代型GCでない場合の例である。第17図(B)において,メモリ使用量200の変化を見ると,GC210によってメモリの空きは回復している。また,GC210後のメモリ使用量200が太線107’を下回っていることから,メモリの空き率がメモリ空き回復しきい値107を上回っていることがわかる。
しかし,GC発生間隔が短くなっている。これは,メモリの絶対量(最大ヒープサイズ220)が小さいなどの理由による。メモリ空き回復しきい値107は,例えば,50%〜60%程度である。
第17図(C)は,第14図のステップS41が成立する場合の例であり,非ダイナミック世代型GCの場合の例である。第17図(C)において,旧世代のメモリ使用量201の変化を見ると,GC210によってメモリの空きは回復している。また,GC210後の旧世代のメモリ使用量201が太線107’を下回っていることから,メモリの空き率がメモリ空き回復しきい値107を上回っている。
しかし,GC発生間隔が短くなっている。また,旧世代のメモリと新世代のメモリの境界221が太線108’を上回っていることから,メモリの全容量に対する新世代容量の割合がnew世代不足警告しきい値108を下回っていることがわかる。これは,新世代容量が小さいからである。new世代不足警告しきい値108は,例えば,5%〜10%程度である。
次に,Javaアプリケーションのスレッドがデッドロックを起こしてるか否かを測定・分析し,警告するスレッド測定・分析手段12について説明する。
Javaのスレッドの状態としては,実行中,実行可能状態で待機中,サスペンド中,スリープ中,ロックの解放待ちで待機中などの状態がある。
前述の第4の従来技術で示したように,スレッドの状態遷移は,Java仮想マシン・プロファイラインタフェースのイベントによって測定することができる。実際に,これらのイベントを分析してスレッドの状態を調べることで,デッドロックしたスレッドを検出する製品がある。
しかし,スレッドの状態遷移は非常に頻繁に起こるものであり,これらのイベントをすべて測定しているとアプリケーションの運用に大きな負荷がかかることとなる。よって,Java仮想マシン・プロファイラインタフェースのイベントによってスレッドの状態遷移を測定して分析するデッドロックの検出は,開発時に行われるべきものである。
これに対し本システムでは,スレッド測定・分析手段12が,アプリケーションの運用に負荷がかからない程度の間隔で定期的にスレッドの状態を測定する。また,ロックの解放待ちで待機中のスレッドを記録し,次の測定のときに同じスレッドが再びロックの解放待ちで待機しているか否かを確認する。連続して待機している場合には,その連続回数をカウントする。ロックの解放待ちでの待機状態の連続回数がデッドロック警告しきい値110を超えたスレッドが2個以上ある場合には,デッドロックの危険性があると判断する。
これにより,アプリケーションの運用時に,その運用に負荷をかけずにデッドロックの危険性を検出することができる。
第18図は,スレッド測定・分析処理フローチャートである。
まず,スレッド測定フラグ102がONであるか否かを判定し(ステップS60),ONでなければ(OFFであれば)ステップS68に進む。
ステップS60においてONであれば,すべてのスレッドの状態を測定し(ステップS61),現在ロックの解放待ちで待機中のスレッドを抽出して記録する(ステップS62)。また,すでに記録されていたスレッドのうち,今回抽出されなかったスレッドの記録を削除する(ステップS63)。
今回初めて抽出されたスレッドの待機状態が連続する回数のカウンタ(これを連続カウンタという)を1とし(ステップS64),前回も抽出されたスレッドの連続カウンタを1インクリメントする(ステップS65)。
次に,“連続カウンタ≧th8(デッドロック警告しきい値110)”を満たすスレッドが2つ以上存在するか否かを判定し(ステップS66),存在しなければステップS68に進む。
ステップS66において存在すれば,デッドロックの危険性があるとの警告(警告w7)を行い(ステップS67),ステップS68に進む。
Java仮想マシン1の起動時にオプションで,または,アプリケーションサーバ2のJava仮想マシン制御手段20(後述)からコマンドで指定された測定間隔だけ,スレッド状態の測定をスリープし(ステップS68),ステップS60に戻る。
以上のように,本システムでは,スレッドの状態遷移をすべて測定する方法ではなく,定期的な測定により判断を行うアルゴリズムを採用しているため,アプリケーションの運用環境に負荷をかけずに,スレッドのデッドロックの危険性を警告することができる。
次に,Java仮想マシン1が分析結果を上位層(アプリケーションサーバ2)に通知し,最適な運用環境になるようにフィードバックする技術手段について説明する。
第19図は,Java仮想マシンとアプリケーションサーバとの連携によるJava仮想マシンへの処理の振り分けを示す図である。第19図のシステムでは,OS4の上層に4つのJava仮想マシン1a〜1dがあり,それぞれが測定・分析手段10a〜10dを有している。Java仮想マシン1a〜1dの上位層にはアプリケーションサーバ2がある。
各Java仮想マシン1a〜1dの起動は,上位層のアプリケーションサーバ2が行っており,各Java仮想マシン1a〜1dとアプリケーションサーバ2との間には密接な関係がある。アプリケーションサーバ2は,複数のJava仮想マシン1a〜1dを起動し,各Java仮想マシン1a〜1dにクライアントからの要求を振り分け,アプリケーションを処理する。
各Java仮想マシン1a〜1d内の測定・分析手段10a〜10dで行った分析の分析結果は,直接にアプリケーションサーバ2に通知される。アプリケーションサーバ2は,受け取った分析結果の通知をアプリケーションの運用環境にフィードバックし,クライアントからの要求をより適切にJava仮想マシン1a〜1dに振り分ける。
例えば,Java仮想マシン1aがアプリケーションサーバ2にメモリ不足でOutOfMemoryのエラーになる危険性が高いという通知を送るものとする。アプリケーションサーバ2は,このJava仮想マシン1aへの処理の振り分けを中止し,Java仮想マシン1aが現在の手持ちの処理を終わらせたところで,新しいJava仮想マシン1b〜1dに処理を振り分けることができる。
まず,Java仮想マシン1とアプリケーションサーバ2とが連携することについて説明する。
第20図は,Java仮想マシンとアプリケーションサーバとの連携を示す図である。アプリケーションサーバ2内のJava仮想マシン制御手段20は,Java仮想マシン1の起動・停止を行い,Java仮想マシン1にアプリケーションの処理を振り分ける手段である。このJava仮想マシン制御手段20とJava仮想マシン1とは,Java仮想マシン連携手段3により互いに連携している。
Java仮想マシン連携手段3は,分析結果通知手段31を備える。この分析結果通知手段31は,プロセス間通信で直接に分析結果を通知する機能と,ファイルなどの媒体を経由して分析結果を通知する機能とを持つ。
Java仮想マシン1内の測定・分析手段10は,分析結果通知手段31を用いて,Java仮想マシン制御手段20に分析結果を送る。
Java仮想マシン制御手段20は,分析結果通知手段31により送られてきた分析結果をもとに,Java仮想マシン1の起動・停止の制御と,Java仮想マシンへのアプケーションの処理の振り分けとを行う。ここで,Java仮想マシン制御手段20内で,Java仮想マシン1からの情報をもとに,Java仮想マシン1の起動・停止やJava仮想マシン1へのアプリケーションの振り分けを最適に行う手段は,Java仮想マシン最適制御手段21である。
また,Java仮想マシン連携手段3は,コマンド通知手段32を備える。このコマンド通知手段32は,プロセス間通信で直接にコマンドを通知する。
Java仮想マシン制御手段20は,コマンド通知手段32を用いて,測定の種類ごとに測定・分析の開始/中断を指示するコマンド,分析結果の判定に使用するしきい値の設定・変更を指示するコマンド,強制ガベージコレクションを指示するコマンドなどを送付する。例えば,警告が長期間に渡って通知されない場合などには,Java仮想マシン制御手段20は,コマンド通知手段32を用いて,Java仮想マシン1にメモリ使用量などの測定の中断を指示するコマンドを送付することができる。
第21図は,分析結果通知処理フローチャートである。ここでは,分析結果通知処理を,Java仮想マシン1の測定・分析手段10側の処理と,アプリケーションサーバ2のJava仮想マシン制御手段20側の処理とにわけて説明する。
第21図(A)は,測定・分析手段10側の分析結果通知処理フローチャートである。測定・分析手段10は,警告があるか否かを判定し(ステップS70),警告があれば,分析結果通知手段31を用いてJava仮想マシン制御手段20に警告を通知する(ステップS71)。このとき回復に必要なメモリ量の情報もあれば,同時に通知する。また,警告は,プロセス間通信で送付してもよいし,ログファイルに出力してもよい。
第21図(B)は,Java仮想マシン制御手段20側の分析結果通知処理フローチャートである。Java仮想マシン制御手段20は,警告を受信したか否かを判定し(ステップS80),警告を受信していれば,その警告をJava仮想マシン最適制御手段21に渡す(ステップS81)。このとき回復に必要なメモリ量の情報も受信していれば,同時に渡す。
第22図は,コマンド通知処理フローチャートである。ここでは,コマンド通知処理を,アプリケーションサーバ2のJava仮想マシン制御手段20側の処理と,Java仮想マシン1の測定・分析手段10側の処理とにわけて説明する。
第22図(A)は,Java仮想マシン制御手段20側のコマンド通知処理フローチャートである。Java仮想マシン制御手段20は,測定・分析手段10への動作環境変更のコマンドがあるか否かを判定し(ステップS90),コマンドがあれば,コマンド通知手段32を用いて測定・分析手段10に設定変更のためのコマンドを送付する(ステップS91)。また,コマンドはプロセス間通信で送付する。
ここで,動作環境変更のコマンドの例としては,例えば,以下のようなものがある。
(1)メモリ使用量の測定開始コマンド
(2)メモリ使用量の測定中断コマンド
(3)スレッドの測定開始コマンド
(4)スレッドの測定終了コマンド
(5)しきい値の設定/変更コマンド
(6)強制ガベージコレクションコマンド
第22図(B)は,測定・分析手段10側のコマンド通知処理フローチャートである。測定・分析手段10は,コマンドを受信したか否かを判定し(ステップS100),コマンドを受信していれば,そのコマンドを実行する(ステップS101)。
ここで,コマンド実行の例としては,例えば,以下のようなものがある。
(1)メモリ使用量の測定開始/中断コマンドであれば,メモリ使用量測定フラグ101をON/OFFする。
(2)スレッドの測定開始/終了コマンドであれば,スレッド測定フラグ102をON/OFFする。
(3)しきい値の設定/変更コマンドであれば,該当するしきい値(103〜110)を設定/変更する。
(4)強制ガベージコレクションコマンドであれば,Java仮想マシン1のガベージコレクション処理を呼ぶ。
次に,分析結果をアプリケーションの運用環境にフィードバックすることについて説明する。
Java仮想マシン1内の測定・分析手段10での分析結果として,OutOfMemoryの危険性の警告,メモリ不足による性能低下の警告,回復に必要なメモリサイズなどの通知をJava仮想マシン制御手段20に送付する。ここで,Java仮想マシン1とJava仮想マシン制御手段20とが,プロセス間通信により直接に結合されているものとすると,通知は直ちにアプリケーションサーバ2に届くこととなる。Java仮想マシン制御手段20は,通知が届いているか否かを定期的に確認し,通知を受け付けたら直ちにその通知をJava仮想マシン最適制御手段21に渡し,アプリケーションの運用環境にフィードバックする。
例えば,Java仮想マシン1からOutOfMemoryの危険性の警告の通知を受けた場合,Java仮想マシン最適制御手段21は,そのJava仮想マシン1へのアプリケーション処理の振り分けを止める。そのJava仮想マシン1が現在処理中のアプリケーションを終了したら,代替のJava仮想マシン1’を立ち上げる。代替のJava仮想マシン1’を立ち上げるときには,Java仮想マシン1から通知された回復に必要なメモリサイズをもとに,代替のJava仮想マシン1’の起動時のオプションで最適なメモリサイズを指定する。
また,Java仮想マシン1からメモリ不足による性能低下の警告の通知を受けた場合,Java仮想マシン最適制御手段21は,次回にJava仮想マシン1を立ち上げるときに,通知された回復に必要なメモリサイズをもとに,Java仮想マシン1起動時のオプションで最適なメモリサイズを指定する。メモリ不足による性能低下の警告を出したJava仮想マシン1へのアプリケーション処理の振り分けを減らすというフィードバックの方法もある。
スレッドのデッドロックの危険性の警告の通知は,Java仮想マシン1の起動やアプリケーション処理の振り分け制御にはフィードバックしない。この情報は,アプリケーションサーバ2のログ情報としてファイルに残し,後のアプリケーションの見直しに利用する。
第23図は,Java仮想マシン最適制御処理フローチャートである。
まず,警告,回復に必要なメモリサイズを受け取り(ステップS110),警告の種類を判定する(ステップS111)。
ステップS111においてOutOfMemoryの危険性の警告(警告w1)であれば,アプリケーションの終了を待って警告の出たJava仮想マシン1を終了させる(ステップS112)。代替のJava仮想マシン1’を起動し(ステップS113),処理を終了する。代替のJava仮想マシン1’の起動時には,受け取った回復に必要なメモリサイズをもとに,オプションで最適なメモリサイズを指定する。
ステップS111においてメモリ不足による性能低下の警告(警告w2)であれば,受け取った回復に必要なメモリサイズを保存し(ステップS114),処理を終了する。次回のJava仮想マシン1の起動時には,保存した回復に必要なメモリサイズをもとに,オプションで最適なメモリサイズを指定する。
ステップS111においてデッドロックの危険性の警告(警告w7)であれば,デッドロックの危険性の警告をログに記録する(ステップS115)。その旨を運用管理者に通知し(ステップS116),処理を終了する。
本システムの効果は,以下のとおりである。本システムでは,メモリの割り当てと解放のすべてを測定する方法ではなく,ガベージコレクションのイベント発生時の測定と,必要に応じてメモリ使用量の定期的な測定とによって判断を行うアルゴリズムを採用しているため,アプリケーションの運用環境に負荷をかけずに,OutOfMemoryの危険性やメモリ不足による性能低下の警告をすることができる。
また,測定したデータを採取して外部プロセスでデータの分析を行う方法では,データの測定から回復に向けたフィードバックまでに時間がかかり,タイムリー性を損なう可能性がある。本システムでは,アプリケーションを動かしているJava仮想マシン内にデータを測定・分析する手段があるため,よりタイムリーなフィードバックを行うことができる。
また,本システムでは,各Java仮想マシンが採用している様々なガベージコレクションに応じて危険性を判断するための改良アルゴリズムを多段的に持っているため,より正確な危険性の判断ができる。
また,単なるOutOfMemoryの危険性やメモリ不足による性能低下の警告だけでは,再度同じような状態になる危険性があるが,本システムでは,Java仮想マシンの最適な運用に必要なメモリ量を合わせて通知するため,回復に向けたより適切なフィードバックを行うことができる。
また,本システムでは,Java仮想マシンのデータを測定・分析し,危険性を通知する手段と上位層(アプリケーションサーバ)のJava仮想マシンを制御する手段とがプロセス間通信により直接つながっており,警告の通知とフィードバックを人が介することなく自動的に行えるため,問題があってから回復を行うまでのタイミングが遅れる危険性が低くなる。
本発明では,Java仮想マシンなどのデータを測定・分析し,危険性を通知する手段と上位層(アプリケーションサーバ)のJava仮想マシンを制御する手段とを連携させ,警告の通知とフィードバックを人手を介することなく自動的に行うことができるため,実行環境におけるメモリ不足の危険性の回避を効率よく行うことができる。
Claims (6)
- 割り当てたメモリの解放をガベージコレクションによって行うプログラム実行環境を有するコンピュータシステムにおける実行環境の危険予測/回避方法であって,
ガベージコレクションのイベント発生時に,ガベージコレクション直後のメモリ使用量を測定する過程と,
前記測定されたメモリ使用量からメモリ不足の危険性を予測する過程と,
メモリの空き容量をA,メモリの全容量をB,メモリ空き回復しきい値をTとしたときに,前記予測されたメモリ不足の危険性を回避するために必要なメモリ量mを,「(A+m)/(B+m)>T」の式を満たすmを求めることにより算出する過程と,
前記予測されたメモリ不足の危険性に対する警告とそれを回避するために必要なメモリ量を他のアプリケーションに通知する過程とを有する
ことを特徴とする実行環境の危険予測/回避方法。 - 前記メモリ不足の危険性の予測およびそれを回避するために必要なメモリ量の算出を,システムが使用するガベージコレクションの種類ごとに対応するアルゴリズム用いて行う
ことを特徴とする請求の範囲第1項記載の実行環境の危険予測/回避方法。 - 割り当てたメモリの解放をガベージコレクションによって行うプログラム実行環境を有するコンピュータシステムにおける実行環境の危険予測/回避方法であって,
ガベージコレクションのイベント発生時に,ガベージコレクション直後のメモリ使用量を測定する過程と,
前記測定されたメモリ使用量からメモリ不足の危険性を予測する過程と,
前記予測されたメモリ不足の危険性を回避するために必要なメモリ量を算出する過程と,
前記予測されたメモリ不足の危険性に対する警告とそれを回避するために必要なメモリ量を他のアプリケーションに通知する過程と,
定期的にスレッドの状態を測定し,ロックの解放待ちで待機中の状態のスレッドを抽出する過程と,
前記抽出されたロックの解放待ちで待機中の状態のスレッドごとに,連続して抽出された回数をカウントする過程と,
前記連続して抽出された回数があらかじめ指定されたしきい値を上回るスレッドが,2つ以上存在する場合に,デッドロックの危険性があると判断し,警告を出力する過程とを有する
ことを特徴とする実行環境の危険予測/回避方法。 - 割り当てたメモリの解放をガベージコレクションによって行うプログラム実行環境を有するコンピュータシステムにおいて,
ガベージコレクションのイベント発生時に,ガベージコレクション直後のメモリ使用量を測定する手段と,
前記測定されたメモリ使用量からメモリ不足の危険性を予測する手段と,
メモリの空き容量をA,メモリの全容量をB,メモリ空き回復しきい値をTとしたときに,前記予測されたメモリ不足の危険性を回避するために必要なメモリ量mを,「(A+m)/(B+m)>T」の式を満たすmを求めることにより算出する手段と,
前記予測されたメモリ不足の危険性に対する警告とそれを回避するために必要なメモリ量を他のアプリケーションに通知する手段とを備える
ことを特徴とする実行環境の危険予測/回避システム。 - 割り当てたメモリの解放をガベージコレクションによって行うプログラム実行環境を有するコンピュータシステムにおいて実行環境の危険予測および回避を行うためのプログラムであって,
ガベージコレクションのイベント発生時に,ガベージコレクション直後のメモリ使用量を測定する処理と,
前記測定されたメモリ使用量からメモリ不足の危険性を予測する処理と,
メモリの空き容量をA,メモリの全容量をB,メモリ空き回復しきい値をTとしたときに,前記予測されたメモリ不足の危険性を回避するために必要なメモリ量mを,「(A+m)/(B+m)>T」の式を満たすmを求めることにより算出する処理と,
前記予測されたメモリ不足の危険性に対する警告とそれを回避するために必要なメモリ量を他のアプリケーションに通知する処理とを,
コンピュータに実行させるための実行環境の危険予測/回避プログラム。 - 割り当てたメモリの解放をガベージコレクションによって行うプログラム実行環境を有するコンピュータシステムにおいて実行環境の危険予測および回避を行うためのプログラムを記録したコンピュータ読み取り可能な記録媒体であって,
ガベージコレクションのイベント発生時に,ガベージコレクション直後のメモリ使用量を測定する処理と,
前記測定されたメモリ使用量からメモリ不足の危険性を予測する処理と,
メモリの空き容量をA,メモリの全容量をB,メモリ空き回復しきい値をTとしたときに,前記予測されたメモリ不足の危険性を回避するために必要なメモリ量mを,「(A+m)/(B+m)>T」の式を満たすmを求めることにより算出する処理と,
前記予測されたメモリ不足の危険性に対する警告とそれを回避するために必要なメモリ量とを他のアプリケーションに通知する処理とを,
コンピュータに実行させるためのプログラムを記録した
ことを特徴とする実行環境の危険予測/回避プログラムの記録媒体。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2003/005814 WO2004099985A1 (ja) | 2003-05-09 | 2003-05-09 | 実行環境の危険予測/回避方法,システム,プログラムおよびその記録媒体 |
Publications (2)
Publication Number | Publication Date |
---|---|
JPWO2004099985A1 JPWO2004099985A1 (ja) | 2006-07-13 |
JP4170988B2 true JP4170988B2 (ja) | 2008-10-22 |
Family
ID=33428596
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2004571568A Expired - Fee Related JP4170988B2 (ja) | 2003-05-09 | 2003-05-09 | 実行環境の危険予測/回避方法,システム,プログラムおよびその記録媒体 |
Country Status (3)
Country | Link |
---|---|
US (1) | US7516292B2 (ja) |
JP (1) | JP4170988B2 (ja) |
WO (1) | WO2004099985A1 (ja) |
Families Citing this family (135)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4589095B2 (ja) * | 2004-12-14 | 2010-12-01 | 三菱電機株式会社 | プログラム実行装置及びプログラム実行方法及びデータ領域管理プログラム |
ATE494580T1 (de) * | 2005-04-18 | 2011-01-15 | Research In Motion Ltd | Zentralisierte speicherverwaltung in drahtlosen endgeräten |
JP4996073B2 (ja) * | 2005-07-13 | 2012-08-08 | 富士通株式会社 | 世代別ガベージコレクションプログラム |
US20070061429A1 (en) * | 2005-09-12 | 2007-03-15 | Microsoft Corporation | Optimizing utilization of application resources |
JP2007087053A (ja) * | 2005-09-21 | 2007-04-05 | Oki Electric Ind Co Ltd | ディスクアレイ制御装置および制御方法 |
US7926071B2 (en) | 2005-10-20 | 2011-04-12 | Microsoft Corporation | Load balancing interfaces |
US8234378B2 (en) | 2005-10-20 | 2012-07-31 | Microsoft Corporation | Load balancing in a managed execution environment |
WO2008054403A2 (en) * | 2005-11-15 | 2008-05-08 | Probity Laboratories, Llc | Systems and methods for identifying, categorizing, quantifying and evaluating risks |
JP5167589B2 (ja) | 2006-02-13 | 2013-03-21 | 富士通株式会社 | アプリケーションサーバ装置および仮想マシンプログラム |
JP2007226399A (ja) * | 2006-02-22 | 2007-09-06 | Hitachi Ltd | 計算機制御方法、計算機、計算機制御プログラム及び計算機システム |
CN100426225C (zh) * | 2006-04-21 | 2008-10-15 | 华为技术有限公司 | 一种内存保护方法及其系统 |
US8161544B2 (en) | 2006-07-19 | 2012-04-17 | Microsoft Corporation | Trusted communications with child processes |
AU2007281686A1 (en) * | 2006-08-07 | 2008-02-14 | Bea Systems, Inc. | System and method for providing hardware virtualization in a virtual machine environment |
US7475214B2 (en) * | 2006-08-16 | 2009-01-06 | International Business Machines Corporation | Method and system to optimize java virtual machine performance |
US7730269B2 (en) * | 2006-08-29 | 2010-06-01 | International Business Machines Corporation | Load management to reduce communication signaling latency in a virtual machine environment |
US7761487B2 (en) * | 2006-12-13 | 2010-07-20 | Computer Associates Think, Inc. | Predicting out of memory conditions using soft references |
US20080162709A1 (en) * | 2006-12-27 | 2008-07-03 | International Business Machines Corporation | System for processing application protocol requests |
US8356286B2 (en) * | 2007-03-30 | 2013-01-15 | Sap Ag | Method and system for providing on-demand profiling infrastructure for profiling at virtual machines |
US8601469B2 (en) * | 2007-03-30 | 2013-12-03 | Sap Ag | Method and system for customizing allocation statistics |
US20080243970A1 (en) * | 2007-03-30 | 2008-10-02 | Sap Ag | Method and system for providing loitering trace in virtual machines |
US8522209B2 (en) * | 2007-03-30 | 2013-08-27 | Sap Ag | Method and system for integrating profiling and debugging |
US7904493B2 (en) * | 2007-03-30 | 2011-03-08 | Sap Ag | Method and system for object age detection in garbage collection heaps |
US8336033B2 (en) * | 2007-03-30 | 2012-12-18 | Sap Ag | Method and system for generating a hierarchical tree representing stack traces |
US8667471B2 (en) * | 2007-03-30 | 2014-03-04 | Sap Ag | Method and system for customizing profiling sessions |
US7937618B2 (en) * | 2007-04-26 | 2011-05-03 | International Business Machines Corporation | Distributed, fault-tolerant and highly available computing system |
US7934052B2 (en) * | 2007-12-27 | 2011-04-26 | Pliant Technology, Inc. | System and method for performing host initiated mass storage commands using a hierarchy of data structures |
US9727436B2 (en) * | 2008-01-02 | 2017-08-08 | International Business Machines Corporation | Adding a profiling agent to a virtual machine to permit performance and memory consumption analysis within unit tests |
JP2009238011A (ja) * | 2008-03-27 | 2009-10-15 | Nec Corp | 実行環境の制御方法およびプログラム |
US8095766B2 (en) * | 2008-04-07 | 2012-01-10 | International Business Machines Corporation | Method and system for approximating object sizes in an object-oriented system |
WO2009139426A1 (ja) * | 2008-05-14 | 2009-11-19 | 日本電気株式会社 | 情報処理システムと情報処理方法 |
US7870257B2 (en) | 2008-06-02 | 2011-01-11 | International Business Machines Corporation | Enhancing real-time performance for java application serving |
EP2237197A1 (en) * | 2009-03-31 | 2010-10-06 | Siemens Aktiengesellschaft | Method for evaluating key production indicators (KPI) in a manufacturing execution system (MES) |
US8365041B2 (en) | 2010-03-17 | 2013-01-29 | Sandisk Enterprise Ip Llc | MLC self-raid flash data protection scheme |
JP5196596B2 (ja) * | 2010-03-19 | 2013-05-15 | Necシステムテクノロジー株式会社 | 障害検知システム、障害検知サーバ、及び、障害検知方法 |
CA2700217C (en) * | 2010-04-01 | 2011-07-19 | Ibm Canada Limited - Ibm Canada Limitee | Write barrier elision for reference arrays |
DE112011103979T5 (de) | 2010-11-30 | 2013-08-29 | International Business Machines Corporation | Computerprogramm und System für ein Verfahren zur Optimierung der Speicherverwaltung einer auf einer virtuellen Maschine ausgeführten Anwendung |
US8909982B2 (en) | 2011-06-19 | 2014-12-09 | Sandisk Enterprise Ip Llc | System and method for detecting copyback programming problems |
US8910020B2 (en) | 2011-06-19 | 2014-12-09 | Sandisk Enterprise Ip Llc | Intelligent bit recovery for flash memory |
US9058289B2 (en) | 2011-11-07 | 2015-06-16 | Sandisk Enterprise Ip Llc | Soft information generation for memory systems |
US8924815B2 (en) | 2011-11-18 | 2014-12-30 | Sandisk Enterprise Ip Llc | Systems, methods and devices for decoding codewords having multiple parity segments |
US9048876B2 (en) | 2011-11-18 | 2015-06-02 | Sandisk Enterprise Ip Llc | Systems, methods and devices for multi-tiered error correction |
US8954822B2 (en) | 2011-11-18 | 2015-02-10 | Sandisk Enterprise Ip Llc | Data encoder and decoder using memory-specific parity-check matrix |
US8458702B1 (en) | 2012-02-28 | 2013-06-04 | Google Inc. | Method for implementing user space up-calls on java virtual machine before/after garbage collection |
US9699263B1 (en) | 2012-08-17 | 2017-07-04 | Sandisk Technologies Llc. | Automatic read and write acceleration of data accessed by virtual machines |
US9753846B2 (en) * | 2012-09-06 | 2017-09-05 | Red Hat, Inc. | Adjusting the operating memory used by a virtual machine during runtime |
US9418003B2 (en) * | 2012-10-10 | 2016-08-16 | Salesforce.Com, Inc. | System, method and computer program product for conditionally performing garbage collection |
US9501398B2 (en) | 2012-12-26 | 2016-11-22 | Sandisk Technologies Llc | Persistent storage device with NVRAM for staging writes |
US9239751B1 (en) | 2012-12-27 | 2016-01-19 | Sandisk Enterprise Ip Llc | Compressing data from multiple reads for error control management in memory systems |
US9612948B2 (en) | 2012-12-27 | 2017-04-04 | Sandisk Technologies Llc | Reads and writes between a contiguous data block and noncontiguous sets of logical address blocks in a persistent storage device |
US9003264B1 (en) | 2012-12-31 | 2015-04-07 | Sandisk Enterprise Ip Llc | Systems, methods, and devices for multi-dimensional flash RAID data protection |
US9454420B1 (en) | 2012-12-31 | 2016-09-27 | Sandisk Technologies Llc | Method and system of reading threshold voltage equalization |
US9329928B2 (en) | 2013-02-20 | 2016-05-03 | Sandisk Enterprise IP LLC. | Bandwidth optimization in a non-volatile memory system |
US9214965B2 (en) | 2013-02-20 | 2015-12-15 | Sandisk Enterprise Ip Llc | Method and system for improving data integrity in non-volatile storage |
US9870830B1 (en) | 2013-03-14 | 2018-01-16 | Sandisk Technologies Llc | Optimal multilevel sensing for reading data from a storage medium |
US9092350B1 (en) | 2013-03-15 | 2015-07-28 | Sandisk Enterprise Ip Llc | Detection and handling of unbalanced errors in interleaved codewords |
US9236886B1 (en) | 2013-03-15 | 2016-01-12 | Sandisk Enterprise Ip Llc | Universal and reconfigurable QC-LDPC encoder |
US9136877B1 (en) | 2013-03-15 | 2015-09-15 | Sandisk Enterprise Ip Llc | Syndrome layered decoding for LDPC codes |
US9367246B2 (en) | 2013-03-15 | 2016-06-14 | Sandisk Technologies Inc. | Performance optimization of data transfer for soft information generation |
US9244763B1 (en) | 2013-03-15 | 2016-01-26 | Sandisk Enterprise Ip Llc | System and method for updating a reading threshold voltage based on symbol transition information |
US9009576B1 (en) | 2013-03-15 | 2015-04-14 | Sandisk Enterprise Ip Llc | Adaptive LLR based on syndrome weight |
US9170941B2 (en) | 2013-04-05 | 2015-10-27 | Sandisk Enterprises IP LLC | Data hardening in a storage system |
US10049037B2 (en) | 2013-04-05 | 2018-08-14 | Sandisk Enterprise Ip Llc | Data management in a storage system |
US9495395B2 (en) * | 2013-04-11 | 2016-11-15 | Oracle International Corporation | Predictive diagnosis of SLA violations in cloud services by seasonal trending and forecasting with thread intensity analytics |
US9159437B2 (en) | 2013-06-11 | 2015-10-13 | Sandisk Enterprise IP LLC. | Device and method for resolving an LM flag issue |
TWI573015B (zh) * | 2013-06-19 | 2017-03-01 | 祥碩科技股份有限公司 | 防超時方法及資料處理系統 |
US9384126B1 (en) | 2013-07-25 | 2016-07-05 | Sandisk Technologies Inc. | Methods and systems to avoid false negative results in bloom filters implemented in non-volatile data storage systems |
US9043517B1 (en) | 2013-07-25 | 2015-05-26 | Sandisk Enterprise Ip Llc | Multipass programming in buffers implemented in non-volatile data storage systems |
US9524235B1 (en) | 2013-07-25 | 2016-12-20 | Sandisk Technologies Llc | Local hash value generation in non-volatile data storage systems |
US9652766B1 (en) * | 2013-08-22 | 2017-05-16 | Amazon Technologies, Inc. | Managing data stored in memory locations having size limitations |
US9639463B1 (en) | 2013-08-26 | 2017-05-02 | Sandisk Technologies Llc | Heuristic aware garbage collection scheme in storage systems |
US9235509B1 (en) | 2013-08-26 | 2016-01-12 | Sandisk Enterprise Ip Llc | Write amplification reduction by delaying read access to data written during garbage collection |
US9519577B2 (en) | 2013-09-03 | 2016-12-13 | Sandisk Technologies Llc | Method and system for migrating data between flash memory devices |
US9442670B2 (en) | 2013-09-03 | 2016-09-13 | Sandisk Technologies Llc | Method and system for rebalancing data stored in flash memory devices |
US9158349B2 (en) | 2013-10-04 | 2015-10-13 | Sandisk Enterprise Ip Llc | System and method for heat dissipation |
US9323637B2 (en) | 2013-10-07 | 2016-04-26 | Sandisk Enterprise Ip Llc | Power sequencing and data hardening architecture |
US9298608B2 (en) | 2013-10-18 | 2016-03-29 | Sandisk Enterprise Ip Llc | Biasing for wear leveling in storage systems |
US9442662B2 (en) | 2013-10-18 | 2016-09-13 | Sandisk Technologies Llc | Device and method for managing die groups |
US9436831B2 (en) | 2013-10-30 | 2016-09-06 | Sandisk Technologies Llc | Secure erase in a memory device |
US9263156B2 (en) | 2013-11-07 | 2016-02-16 | Sandisk Enterprise Ip Llc | System and method for adjusting trip points within a storage device |
US9244785B2 (en) | 2013-11-13 | 2016-01-26 | Sandisk Enterprise Ip Llc | Simulated power failure and data hardening |
US9152555B2 (en) | 2013-11-15 | 2015-10-06 | Sandisk Enterprise IP LLC. | Data management with modular erase in a data storage system |
US9703816B2 (en) | 2013-11-19 | 2017-07-11 | Sandisk Technologies Llc | Method and system for forward reference logging in a persistent datastore |
US9520197B2 (en) | 2013-11-22 | 2016-12-13 | Sandisk Technologies Llc | Adaptive erase of a storage device |
US9280429B2 (en) | 2013-11-27 | 2016-03-08 | Sandisk Enterprise Ip Llc | Power fail latching based on monitoring multiple power supply voltages in a storage device |
US9122636B2 (en) | 2013-11-27 | 2015-09-01 | Sandisk Enterprise Ip Llc | Hard power fail architecture |
US9520162B2 (en) | 2013-11-27 | 2016-12-13 | Sandisk Technologies Llc | DIMM device controller supervisor |
US9582058B2 (en) | 2013-11-29 | 2017-02-28 | Sandisk Technologies Llc | Power inrush management of storage devices |
US9250676B2 (en) | 2013-11-29 | 2016-02-02 | Sandisk Enterprise Ip Llc | Power failure architecture and verification |
US9092370B2 (en) | 2013-12-03 | 2015-07-28 | Sandisk Enterprise Ip Llc | Power failure tolerant cryptographic erase |
US9235245B2 (en) | 2013-12-04 | 2016-01-12 | Sandisk Enterprise Ip Llc | Startup performance and power isolation |
US9747028B1 (en) * | 2013-12-13 | 2017-08-29 | Amazon Technologies, Inc. | Artificial memory pressure for low memory machine |
US9129665B2 (en) | 2013-12-17 | 2015-09-08 | Sandisk Enterprise Ip Llc | Dynamic brownout adjustment in a storage device |
US9549457B2 (en) | 2014-02-12 | 2017-01-17 | Sandisk Technologies Llc | System and method for redirecting airflow across an electronic assembly |
US9497889B2 (en) | 2014-02-27 | 2016-11-15 | Sandisk Technologies Llc | Heat dissipation for substrate assemblies |
US9703636B2 (en) | 2014-03-01 | 2017-07-11 | Sandisk Technologies Llc | Firmware reversion trigger and control |
US9348377B2 (en) | 2014-03-14 | 2016-05-24 | Sandisk Enterprise Ip Llc | Thermal isolation techniques |
US9519319B2 (en) | 2014-03-14 | 2016-12-13 | Sandisk Technologies Llc | Self-supporting thermal tube structure for electronic assemblies |
US9485851B2 (en) | 2014-03-14 | 2016-11-01 | Sandisk Technologies Llc | Thermal tube assembly structures |
US9448876B2 (en) | 2014-03-19 | 2016-09-20 | Sandisk Technologies Llc | Fault detection and prediction in storage devices |
US9390814B2 (en) | 2014-03-19 | 2016-07-12 | Sandisk Technologies Llc | Fault detection and prediction for data storage elements |
US9454448B2 (en) | 2014-03-19 | 2016-09-27 | Sandisk Technologies Llc | Fault testing in storage devices |
US9626400B2 (en) | 2014-03-31 | 2017-04-18 | Sandisk Technologies Llc | Compaction of information in tiered data structure |
US9626399B2 (en) | 2014-03-31 | 2017-04-18 | Sandisk Technologies Llc | Conditional updates for reducing frequency of data modification operations |
US9390021B2 (en) | 2014-03-31 | 2016-07-12 | Sandisk Technologies Llc | Efficient cache utilization in a tiered data structure |
US9697267B2 (en) | 2014-04-03 | 2017-07-04 | Sandisk Technologies Llc | Methods and systems for performing efficient snapshots in tiered data structures |
US10372613B2 (en) | 2014-05-30 | 2019-08-06 | Sandisk Technologies Llc | Using sub-region I/O history to cache repeatedly accessed sub-regions in a non-volatile storage device |
US9645749B2 (en) | 2014-05-30 | 2017-05-09 | Sandisk Technologies Llc | Method and system for recharacterizing the storage density of a memory device or a portion thereof |
US8891303B1 (en) | 2014-05-30 | 2014-11-18 | Sandisk Technologies Inc. | Method and system for dynamic word line based configuration of a three-dimensional memory device |
US9093160B1 (en) | 2014-05-30 | 2015-07-28 | Sandisk Technologies Inc. | Methods and systems for staggered memory operations |
US10146448B2 (en) | 2014-05-30 | 2018-12-04 | Sandisk Technologies Llc | Using history of I/O sequences to trigger cached read ahead in a non-volatile storage device |
US10162748B2 (en) | 2014-05-30 | 2018-12-25 | Sandisk Technologies Llc | Prioritizing garbage collection and block allocation based on I/O history for logical address regions |
US9703491B2 (en) | 2014-05-30 | 2017-07-11 | Sandisk Technologies Llc | Using history of unaligned writes to cache data and avoid read-modify-writes in a non-volatile storage device |
US10656840B2 (en) | 2014-05-30 | 2020-05-19 | Sandisk Technologies Llc | Real-time I/O pattern recognition to enhance performance and endurance of a storage device |
US10656842B2 (en) | 2014-05-30 | 2020-05-19 | Sandisk Technologies Llc | Using history of I/O sizes and I/O sequences to trigger coalesced writes in a non-volatile storage device |
US10114557B2 (en) | 2014-05-30 | 2018-10-30 | Sandisk Technologies Llc | Identification of hot regions to enhance performance and endurance of a non-volatile storage device |
US9070481B1 (en) | 2014-05-30 | 2015-06-30 | Sandisk Technologies Inc. | Internal current measurement for age measurements |
US9652381B2 (en) | 2014-06-19 | 2017-05-16 | Sandisk Technologies Llc | Sub-block garbage collection |
US9443601B2 (en) | 2014-09-08 | 2016-09-13 | Sandisk Technologies Llc | Holdup capacitor energy harvesting |
US9413626B2 (en) * | 2014-12-05 | 2016-08-09 | Amazon Technologies, Inc. | Automatic management of resource sizing |
CA2876379A1 (en) * | 2014-12-29 | 2016-06-29 | Adam J. Storm | Memory management in presence of asymmetrical memory transfer costs |
JP6447348B2 (ja) | 2015-05-01 | 2019-01-09 | 富士通株式会社 | ダンプデータ管理プログラム、ダンプデータ管理方法、およびダンプデータ管理装置 |
US10248561B2 (en) | 2015-06-18 | 2019-04-02 | Oracle International Corporation | Stateless detection of out-of-memory events in virtual machines |
US11327797B2 (en) | 2016-05-09 | 2022-05-10 | Oracle International Corporation | Memory usage determination techniques |
US9672062B1 (en) * | 2016-12-01 | 2017-06-06 | Red Hat, Inc. | Batched memory page hinting |
US10198674B2 (en) * | 2016-12-22 | 2019-02-05 | Canon Kabushiki Kaisha | Method, apparatus and system for rendering a graphical representation within limited memory |
US10565104B2 (en) * | 2017-08-01 | 2020-02-18 | International Business Machines Corporation | System and method to manage and share managed runtime memory for JAVA virtual machine |
US10579439B2 (en) | 2017-08-29 | 2020-03-03 | Red Hat, Inc. | Batched storage hinting with fast guest storage allocation |
US10956216B2 (en) | 2017-08-31 | 2021-03-23 | Red Hat, Inc. | Free page hinting with multiple page sizes |
US10747566B2 (en) | 2017-11-21 | 2020-08-18 | International Business Machines Corporation | Restarting application servers |
US10474382B2 (en) | 2017-12-01 | 2019-11-12 | Red Hat, Inc. | Fast virtual machine storage allocation with encrypted storage |
KR102700419B1 (ko) * | 2018-09-04 | 2024-08-30 | 삼성전자주식회사 | 전자장치 및 그 제어방법 |
US10884641B2 (en) | 2019-04-16 | 2021-01-05 | Paypal, Inc. | Low latency gateway for an asynchronous orchestration engine using direct memory |
US11436141B2 (en) | 2019-12-13 | 2022-09-06 | Red Hat, Inc. | Free memory page hinting by virtual machines |
US11144369B2 (en) | 2019-12-30 | 2021-10-12 | Bank Of America Corporation | Preemptive self-healing of application server hanging threads |
CN111831467B (zh) * | 2020-07-21 | 2024-09-03 | 北京思特奇信息技术股份有限公司 | java进程内存溢出自熔断的方法、系统和电子设备 |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH0527993A (ja) | 1991-07-24 | 1993-02-05 | Toshiba Corp | デツドロツク検出処理方式 |
JPH05227993A (ja) * | 1992-02-24 | 1993-09-07 | Nippon Oil & Fats Co Ltd | 抗酸化活性測定方法 |
JP3027845B2 (ja) * | 1997-11-21 | 2000-04-04 | オムロン株式会社 | プログラム制御装置および方法 |
JP3795669B2 (ja) * | 1998-04-28 | 2006-07-12 | 富士通株式会社 | メモリ管理装置およびメモリ管理プログラムを記憶した記憶媒体 |
JP2001265650A (ja) * | 2000-03-15 | 2001-09-28 | Omron Corp | メモリリソース使用状況監視装置及びメモリリソース使用状況監視方法 |
US6542911B2 (en) * | 2001-03-01 | 2003-04-01 | Sun Microsystems, Inc. | Method and apparatus for freeing memory from an extensible markup language document object model tree active in an application cache |
-
2003
- 2003-05-09 WO PCT/JP2003/005814 patent/WO2004099985A1/ja active Application Filing
- 2003-05-09 JP JP2004571568A patent/JP4170988B2/ja not_active Expired - Fee Related
-
2005
- 2005-06-29 US US11/170,217 patent/US7516292B2/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JPWO2004099985A1 (ja) | 2006-07-13 |
WO2004099985A1 (ja) | 2004-11-18 |
US7516292B2 (en) | 2009-04-07 |
US20050240641A1 (en) | 2005-10-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4170988B2 (ja) | 実行環境の危険予測/回避方法,システム,プログラムおよびその記録媒体 | |
JP4920391B2 (ja) | 計算機システムの管理方法、管理サーバ、計算機システム及びプログラム | |
US8886866B2 (en) | Optimizing memory management of an application running on a virtual machine | |
US7730364B2 (en) | Systems and methods for predictive failure management | |
US8365183B2 (en) | System and method for dynamic resource provisioning for job placement | |
JP3944167B2 (ja) | サーバ・ネットワークのコンピューティング・リソースを管理する自動化された方法 | |
US7203746B1 (en) | System and method for adaptive resource management | |
US6662204B2 (en) | Thread control system and method in a computer system | |
JPH08328880A (ja) | 複数のアプリケーションプログラムを同時に実行できるオペレーティングシステムにおける計算機運転管理システム | |
US20080147705A1 (en) | Predicting out of memory conditions using soft references | |
US20200319935A1 (en) | System and method for automatically scaling a cluster based on metrics being monitored | |
US20100286952A1 (en) | Method, system, and computer program product for determining a hang state and distinguishing a hang state from an idle state | |
US20030014507A1 (en) | Method and system for providing performance analysis for clusters | |
US7962692B2 (en) | Method and system for managing performance data | |
JP4761229B2 (ja) | 運用管理装置、運用管理方法ならびにプログラム | |
JP4485592B2 (ja) | 計算機システムおよび計算機システムの計算機制御方法 | |
JP5821471B2 (ja) | 情報処理装置、プロセス監視方法、プロセス監視プログラム、記録媒体 | |
JP2012074056A5 (ja) | ||
JP2007156976A (ja) | 情報処理システム | |
JP4408122B2 (ja) | 計算機システム、計算機システムの計算機制御方法および計算機制御プログラム | |
US11899578B2 (en) | System and method for dynamic selection of a garbage collector for java-based microservices | |
JP2005182594A (ja) | コンピュータ及びプログラム | |
CN117806778B (zh) | 资源管理方法、系统、设备及介质 | |
KR20000015430A (ko) | 컴퓨터 시스템의 자동화된 작업 스케쥴러 | |
CN116915776A (zh) | 数据节点扩容方法、装置、设备及计算机可读存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080507 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080707 |
|
RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20080707 |
|
RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20080707 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080805 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080807 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110815 Year of fee payment: 3 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120815 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120815 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130815 Year of fee payment: 5 |
|
LAPS | Cancellation because of no payment of annual fees |