GC周りでトラブルシューティングした際の経験や、Web等で調べたことをまとめてみる。 前提 ・JVMは、Sun Javaを想定。(他は使ったことないです。。。) ・Sun Java 1.5-1.6を想定。 目標 マイナーGC、Full GCそれぞれが頻発することなく、かつそれぞれの実行時間を1秒未満に抑えること。 マイナーGCは1秒未満どころではなく、もっと短くなるべき。どれくらいが理想かは？(0.1秒未満ぐらいを目指したい？) 連続した負荷状態(想定されるピークアクセス)でもOutOfMemoryErrorが発生しないこと。 理想的な状態は、上記に加えて、Full GCの発生が低頻度であること。 具体的には、できるだけマイナーGCで短命オブジェクト(1回使ったらもう使わないようなオブジェクト。逆にセッションオブジェクト等は長命オブジェクトとなる)を破棄させて、短命オブジェクトが、Tenu

ガーベッジコレクション（以下GC）やメモリについて、あやふやのままにしていたところが多かったので、調べてみたことをメモしておきます。 メモリについて プログラムの使用するメモリは、レジスタ、スタック、ヒープなど用途によって分けられますが、高級言語になるにつれてこれらは隠蔽されています。 Javaの場合はスタックとヒープ領域の二つに分けられます。 スタック スタックはメソッド起動ごとにフレームを出し入れする線形のデータ構造です。このフレームの中にローカル変数や引数などのデータを持っています。 メソッドが終了するとフレームは破棄されるので、寿命が短いことが特徴です。 スタックはスレッドごとに割り当てられます。 ヒープ インスタンスなどを保持する領域です。GCによって、メモリの管理がなされます。 JVMで一つ割り当てられ、全てのスレッドから共有されます。 クラス構造などの静的なデータも保持されて

J2EEがミッションクリティカルな分野に適用されるようになり、Javaのパフォーマンスチューニングの重要性はさらに高まっています。パフォーマンスチューニングにはさまざまなパラメータがありますが、中でもJava VMに関連するチューニングの効果は大きいといわれています。本稿は、Java VMに関連するチューニング手法を学ぶための前提知識を提供することを目的にしています（編集部）。 Java VMに関連するチューニングを行い、J2EEアプリケーションのパフォーマンスを上げるためには、Java VMについて詳しく知る必要があります。本稿は2回に渡ってJava VMの基本構造と動作原理を詳細に解説しますが、内容を理解するためにはプログラムがコンピュータ上で動作する基本原理とJava VMの基本用語を知っている必要があります。Java VMの基本用語に関しては、「実行スピードに挑戦するJavaアーキ

GCを適切に行わせるためのヒープサイズの設定 JVMにGCを適切に行わせるにはヒープサイズを適切に設定（New領域サイズ、Old領域サイズ、領域サイズのバランスなど）する必要があります。当然、適切なヒープサイズはアプリケーションに依存します。一般にヒープサイズが小さいとGCが頻発してアプリケーションのパフォーマンスが低下します。さらに、ヒープサイズが必要量を下回る場合はOutOfMemoryErrorが発生してアプリケーションが停止してしまいます。一方、ヒープサイズが大きいと、GCの起動回数は減りますが、GC1回当たりの処理時間、すなわちアプリケーション停止状態が長くなり、アプリケーションの応答時間に問題が出る場合もあります。システムの物理メモリのフリー領域が不足するまでヒープサイズを大きくすると、物理メモリからスワップ領域へのページングが起こってしまい、かなりのパフォーマンスが劣化する可

このところ、Javaのスレッドやヒープメモリ関連の問題に悩まされているので、その手の調査ツールをよく使用する。 そんなわけで(謎)、お気に入りのツールたちのメモ。 侍 侍 - ログ , スレッドダンプ解析ツール 私自身は主にjavacoreの調査に使用しているが、「侍 はタブ表示できる GUI の tail ツールです。」ということで、UNIXのtailコマンドと同じことができたり、またスレッドダンプを可視化したり、verbosegcログをグラフ表示したりできる。 昔、WAS上で動作するアプリが無応答になる原因を調査したときにも使用していたが、このツールはデッドロックしているスレッドにどくろマークが付くので、「あ、どくろちゃん出たっ！」などと言いながら調査をしていた記憶が‥思い出したくない記憶だけど‥ SendSignal SendSignal javacoreを採取する際に、コマンドライ

IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

本記事は、HP-UX Developer Edgeに掲載された記事を株式会社アットマーク・アイティおよび本記事の筆者が独自の判断のもとに加筆・修正したものです。 今回は、Javaにおけるヒープ・メモリ管理の詳細を説明します。JVMのヒープ・メモリの中で、新しいオブジェクトと古いオブジェクトがどのように配置されるかを理解することで、ヒープ・メモリが有効に利用されているか否かを判断することができます。また、JVMが出力するガベージ・コレクションのログを解析し、オプションの指定によってヒープ・メモリのサイズを適切にチューニングする方法を紹介します。 Java ヒープ・メモリの構造 Javaにおけるガベージ・コレクションのメカニズムを理解するには、まずヒープ・メモリの構造を知っておく必要があります。 図1は、JVM におけるヒープ・メモリの構造を示したものです。この図が示すように、ヒープ・メモリの

Geisha Tokyo Entertainment: How to make a cool Social Application for mobile

– その1: 自宅サーバがハング – その2: フリーズの原因はガベージコレクション – その3: 侍でヒープ使用量を確認 – その4: リーク箇所を確認する色々な方法 – その5: Memory Analyzer でヒープダンプを解析(最終回) 延々と連載してきたメモリリークトラブルシューティング記もいよいよ最終回です。 今回のメモリリーク現象はリークの再現方法がわからないため、運用環境から詳細なデータが取得できるheapdumpを取得した、というのが前回までのあらすじです。 次は、ヒープダンプの解析。 ヒープダンプは JDK に付属の jmap コマンドで取得します。 jmap -heap:format=x [pid] または jmap -heap:format=b [pid] といった形で実行するとヒープダンプを xml 形式、またはバイナリ形式で記録できます。 通常生のヒープダンプ

– その1: 自宅サーバがハング – その2: フリーズの原因はガベージコレクション JBoss のサーバログ(server/$MY_CONFIG/logs/server.log) を見ても特に顕著なメッセージは見られません。 普段からフリーズしたらとにかくスレッドダンプ！と口を酸っぱくしています。 私自身スレッドダンプを見るのが趣味みたいなものですが、今回はスレッドダンプは必要ありませんでした。 標準出力をみると、原因は明らか。 . . . 306122.554: [Full GC 306122.554: [Tenured: 546171K->546171K(546176K), 4.0978385 secs] 607611K->607602K(607616K), [Perm : 60798K->60798K(60928K)], 4.0982228 secs] 306126.672: [F

– その1: 自宅サーバがハング – その2: フリーズの原因はガベージコレクション – その3: 侍でヒープ使用量を確認 前回のエントリで、フリーズの原因が Full GC の頻発にあることまで書きました。 GC 、特にマーキングと呼ばれるオブジェクトが回収可能かどうかを確認する処理は重たいです。 Sun, HP, Apple, OpenJDK といったブランド/ベンダの JVM は世代別GC(Generational GC)と呼ばれるアルゴリズムを採用しています。 #最近の IBM JDK は Generational GC を選択することもできるようになっています 世代別 GC では VM のヒープ領域を大きく New 領域、Old 領域と分けておき、生成されたばかりのオブジェクトは New 領域に、長生きするオブジェクトは Old 領域にわけます。 長生きしているかどうかはオブジェ

– その1: 自宅サーバがハング – その2: フリーズの原因はガベージコレクション – その3: 侍でヒープ使用量を確認 – その4: リーク箇所を確認する色々な方法 前回のエントリではOld 領域にオブジェクトが溢れていることを突きとめた経緯を書きました。 次は、ヒープ領域にどんなオブジェクトが溜まっているのか確認する必要があります。 リークしているオブジェクトを検出する方法はいくつかあり、それぞれ以下のような特徴があります。 1. プロファイラ リーク検出を行う上で一番有名な方法。 JVM に特殊なフックをかけ、オブジェクトの生成、GC 等の挙動を監視します。 アプリケーションを動作させながら増加してくオブジェクトだけを抽出したり、オブジェクト生成に至るスタックトレースを確認したりと様々な視点で VM を調査できるのが特徴です。 一般的にプロファイラを使うと VM のパフォーマンスが

肥え続けるTomcatと胃を痛めるトラブルハッカー：現場から学ぶWebアプリ開発のトラブルハック（8）（1/3 ページ） 本連載は、現場でのエンジニアの経験から得られた、APサーバをベースとしたWebアプリ開発における注意点やノウハウについて解説するハック集である。現在起きているトラブルの解決や、今後の開発の参考として大いに活用していただきたい。（編集部） メモリリークと聞いて、良いイメージを思い浮かべる開発者は少ないだろう。経験したことのある人にとっては、思い出したくない過去の記憶がよみがえるかもしれない。もしかしたら、その単語を聞くだけで胃が痛くなる人もいるかもしれない。筆者もかつてはその1人であった。 前々回の記事では、WebサーバとTomcatの間の接続において、スレッド数の不整合により発生したトラブル事例を、前回はTomcatとDBサーバの間のトラブル事例を紹介した。今回もTom

本記事は、HP-UX Developer Edgeに掲載された記事を株式会社アットマーク・アイティおよび本記事の筆者が独自の判断のもとに加筆・修正したものです。 Java言語では、Javaオブジェクトに対するメモリ領域の割り当てや解放をJVM（Java仮想マシン）が自動的に行います。この自動解放メカニズムを「ガベージ・コレクション」と呼びます。ガベージ・コレクションは、Javaプログラムのパフォーマンスに決定的な影響を与えるため、その振る舞いを把握することがチューニング作業において極めて重要となります。そこで今回は、Javaのガベージ・コレクションの役割を説明し、ログの記録方法などを解説します。 Javaオブジェクトとヒープ Javaプログラムの実行中には、Javaオブジェクトが生成されます。Javaオブジェクトは、Javaプログラムの起動時に生成される場合もあれば、実行中に必要に応じて生

JavaのGC頻度に惑わされた年末年始の苦いメモリ：現場から学ぶWebアプリ開発のトラブルハック（9）（1/3 ページ） 本連載は、現場でのエンジニアの経験から得られた、APサーバをベースとしたWebアプリ開発における注意点やノウハウについて解説するハック集である。現在起きているトラブルの解決や、今後の開発の参考として大いに活用していただきたい。（編集部） Java言語を利用するようになって、システムを開発するうえで楽になった要素は何かというアンケートがあったとき、読者の皆さんならどのように回答するだろうか。私は迷わず、「メモリ管理」と回答する。 同時に、Javaを利用してシステム開発を行う際に、注意していること、悩まされたことは何かとアンケートがあれば、「GC（ガベージ・コレクション）」と回答するだろう。 多くのシステム開発の現場では、いまこの瞬間も、JavaのGCの挙動に悩まされ、GC

今回の概要 本稿ではWebアプリケーションの開発プロジェクトで実際に直面したメモリに関するトラブル事例の中からjava.lang.OutOfMemoryErrorを題材としたTipsを紹介する。 帰宅直前に、突然電話が鳴り響く 業務を終えて帰宅しようとしたとある夜、突然電話が鳴る。相手は社内のプロジェクトのマネージャである。 「現在、テストを実施しているが、数分経つとOutOfMemoryErrorが発生してアプリケーションが落ちてしまう。再起動を掛けると、また順調に動くが、しばらく利用していると、同じようにOutOfMemoryErrorが発生する。メモリ不足のエラーなので、物理メモリを増やそうかと思っているが、物理メモリ増設の前に、アプリケーションという観点からメモリ不足を引き起こす問題がないか調査してほしい」 取りあえず、原因を探るために現場に急行した。 現場にてトラブルの詳細をヒア

本連載では、現場でのエンジニアの経験から得られた、アプリケーション・サーバをベースとしたWebシステム開発における注意点やヒントについて解説する。巷のドキュメントではなかなか得られない貴重なノウハウが散りばめられている。読者の問題解決や今後システムを開発する際の参考として大いに活用していただきたい。（編集局） 今回のワンポイント Javaアプリケーションを動作させていて、「OutOfMemoryが出た」「Java VMが落ちた」という問い合わせを受けることがある。この場合、たいていはアプリケーションの問題や、設定の問題であることが多い。本稿では、HP-UX上でのJava VMを例に、OutOfMemoryが出る原因とその対処方法を紹介する。なお、本稿に登場する用語は第6回「APサーバからの応答がなくなった－GCをチューニングしよう－」で解説しているので、参照してから読んでほしい。 Old領

Javaがヒープの管理にGCを使用しているのは、読者の皆さんもご存じの通りです。GCの手法にはいろいろありますが、HotSpot VMが採用しているのが世代別GCです。今回は、世代別GCの概要と問題点を解説したうえで、これを解決するために導入されたGarbage First GCについて説明します。 世代別GCの概要と問題点 世代別GCは若いインスタンスと時間を経たインスタンスを別々の領域に配置し、管理する手法です。これは寿命の短いインスタンスほど多いという性質をベースにしています。 若いインスタンスが配置される領域をヤング領域、時間を経たインスタンスを配置する領域をオールド領域とよび、それぞれの領域で異なるGCの手法を使用します。つまり、ヤングとオールドという世代の異なる領域を、それぞれ異なるGCで管理するのが世代別GCというわけです。 ヤング領域には高速ですが漏れのあるGCを用います。

“Stop the World”を防ぐコンカレントGCとは？：現場から学ぶWebアプリ開発のトラブルハック（2）（1/2 ページ） 本連載は、現場でのエンジニアの経験から得られた、APサーバをベースとしたWebアプリ開発における注意点やノウハウについて解説するハック集である。現在起きているトラブルの解決や、今後の開発の参考として大いに活用していただきたい。（編集部） Full GC問題の時代が再び到来！ それまで順調に動いていたはずのWebアプリケーションが、ある時突然、応答を返さなくなる。そして、運用者があたふたしている間に、何事もなかったかのように再び動き出す。 Javaで構築したシステムにかかわる者ならば誰しもが体験するであろう事象、そうFull GC（ガベージ・コレクション）だ。Full GCが行われている間、すべてのアプリケーションスレッドは停止する。この事象は“Stop the