sun jdk 6u13 での実行結果。Client VMだとSerialGCがデフォルトで、Server VMだとParallelGCがデフォルトっぽい。コンカレントGCを有効にするには明示的に指定しないといけない。コレクタ名だけ見てると、-XX:+UseConcMarkSweepGCと-Xconcgcは等価。 $ java -XX:+UseSerialGC GC Copy MarkSweepCompact $ java -XX:+UseParallelGC GC PS Scavenge PS MarkSweep $ java -Xconcgc GC ParNew ConcurrentMarkSweep $ java -XX:+UseConcMarkSweepGC GC ParNew ConcurrentMarkSweep GC.java $ cat GC.java import jav
1. Introduction The Java™ Platform, Standard Edition (Java SE™) is used for a wide variety of applications, from small applets on desktops to web services on large servers. In support of this diverse range of deployments, the Java HotSpot™ virtual machine implementation (Java HotSpot™ VM) provides multiple garbage collectors, each designed to satisfy different requirements. This is an important pa
Webシステムの安定動作には、メモリ使用量の適切な見積もりが不可欠。だがJavaVMでメモリがどのように管理されるかを理解しているだろうか? メモリに関する問題が発生すると、知識や技術資料の不足によって問題が長期化しがち。JavaVMでどのようにメモリが管理されているかを理解し、正確なメモリサイジングやメモリ関係のトラブルの早期解決へとつなげよう。 JavaVMのメモリ構造を理解しよう まず、JavaVMがどのようにメモリを使っているかを理解しておこう。JavaVMがプログラムを実行すると、Javaのプロセスによってメモリが使用される。Javaのプロセスでは、Javaヒープ、Permヒープ、Cヒープ、およびスレッドスタックという4つのメモリ領域を使用する。 Javaヒープはアプリケーションプログラムの各種オブジェクトを格納する領域であり、Classのnewで確保される。JavaヒープはNe
Re: メモリリークトラブルシューティング記 - その4: リーク箇所を確認する色々な方法 ほほう。YourKit やっぱいいんだ。 今度オープンソース開発向けライセンス申請... Re: メモリリークトラブルシューティング記 - その4: リーク箇所を確認する色々な方法 個人的な経験からすると、YourKit は素晴らしかったね。 OptimizeIT がウンコに思えたなー、当時。って、何年前... Re: ヨドバシ.com のサーバーは WebLogic ではなく Tomcat だと思う理由 そう。2 ちゃんでは、キノコよばわりされているよ。... 11月28日 - JBoss COMPASS Tokyo 2008 先日もご紹介したイベントですが、そろそろ... Mars Phoenix からの通信途絶える 火星からの鮮明な画像を送ってきたり、水(... メモリリークトラブルシューティ
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
2007/xx/xx xx:28:50 org.apache.tomcat.util.threads.ThreadPool logFull 致命的: すべてのスレッド (200) が現在稼働中で待機しています。maxThreads (200) を増やすか、そのサーブレットのステータスをチェックしてください これは、Tomcatの持つスレッドプールが最大スレッド数に達してしまったという内容のメッセージだ。Tomcatは、スレッドの生成/破棄のオーバヘッドを削減するため、スレッドプーリングの機能を持っている。スレッドの数が多過ぎるとサーバ上のリソースを消費し過ぎてしまうため、プールには上限値として最大スレッド数を設定できる。 ■Tomcat解剖 それでは、最大スレッド数に達した場合にはどうなってしまうのか。それを理解するためには、Tomcat内部の動作に関する知識が必要となる。図3はTomca
PrintClassHistogramオプションで、迷宮入りを防げ!! 残された道はただ1つ。いまもメモリリークが発生している本番環境で、何としても発生状況の情報を取得することだ。プロファイラを用いることが確実だが、性能劣化が確実に予想されるため、本番環境に導入することは考えられない。 どうすれば、と考えあぐねていたところ、一緒に解析に当たっていた同僚より「PrintClassHistogramオプションが使えるのではないか」との情報を得た。試験環境でサービスへの影響がないことを確認した後、プロジェクトメンバが見守る中、最後の望みを賭けてPrintClassHistogramを本番環境へ適用した。 ■PrintClassHistogramオプションとは? このオプションを知らない方のために、PrintClassHistogramオプションについて説明しよう。PrintClassHistog
GCの動きを見たいときは -Xloggc: や -XX:+PrintGCDetails をつけて、GCViewer で見ていた。 これは時系列でのGCの動きや、メモリの推移を知るには便利だけど、細かい動きについては解り辛い。概要を知るには便利だけど、細かく知りたい時は不便という感じ。 # 使いこなせていないだけかもしれないけど。 GCが起きるメモリリークプログラムをさくっと書いてみる。 import java.util.List; import java.util.ArrayList; public class GCTest { public static void main(String[] args){ List<String> list = new ArrayList<String>(); for(;;){ String str = new String("hoge"); list.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く