無限ルーパー - javaのヒープメモリの使用状況を確認する
先日、Tomcatのメモリリークに遭遇した。 直接の原因は、Tomcatのセッションが開放されないことで、ヒープメモリ不足が発生していたことだった。 この問題、ggったら結構よくある問題ようで。 そんなわけで、ヒープメモリやGCについて 詳しく調べることになったのでまとめておく。 javaを語る上で外せないヒープメモリについては、 素晴らしい説明資料が数多くあるため、参考になったサイトを以下に挙げておく。 「Javaのヒープ・メモリ管理の仕組み」 http://www.atmarkit.co.jp/fjava/rensai3/devedge03/devedge03_1.html 「JavaVMのメモリ管理に関するまとめ（Javaヒープ、GC、ダンプ等）」 http://d.hatena.ne.jp/tanakakns/20120508/1336467306 「ガベージコレクタの仕組みを理解
無限ルーパー - Tomcat
先日、負荷をかけながらTomcatのヒープ領域を眺めている時、 Tomcatを再起動した直後であっても、ヒープのOLD領域の利用率が高いことに気づいた。 どうやらTomcatは、停止時にセッション情報をディスクに一度保存し、 起動時にそれを読み出して、セッション情報が失われないようにしているらしい。 これはデフォルト設定であるようだ。 セッションタイムアウトが正しく設定されていない場合などには、 古い情報も残り続けてしまい、JVMのヒープメモリ領域を逼迫させる要因になりうる。 特に検証として実施している時には、設定をOFFにするか、毎回起動時に削除するようにしたい。 セッション情報は以下に保存されている。 $CATALINA_HOME/work/Catalina/localhost/_/SESSIONS.ser Tomcat停止時に作成されるこのファイルを削除することで、 保存されたセッシ
Javaメモリ、GCチューニングとそれにまつわるトラブル対応手順まとめ - 日記のような何か
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
