Understanding Memory Management of JavaVM
in 15 minutesクロスクラウドデータ管理の未来：�BigLakeで実現するAWS S3とBigQueryのデータ統合戦略/cross-cloud-biglake-s3-strategy-20240712
第13章 パフォーマンスチューニング
まず wiki の「Performance Tuning」を読んでください。この記事には、RAM、圧縮、JVM の設定など、パフォーマンスに関係する重要な要素についての全般的な説明があります。記事を読んだら、ここへ戻ってきてください。以下では、さらに詳しい情報へのポインタを示します。 Todd Lipcon は、「Avoiding Full GCs with MemStore-Local Allocation Buffers」と題したプレゼンテーションの中で、特に HBase の読み込み時によく発生する、すべてが止まったかのような状態になるガベージコレクション、すなわち CMS が失敗するケースと、古い世代のヒープがフラグメンテーション化するケースの 2 つを取り上げています。最初のケースに対処するには、-XX:CMSInitiatingOccupancyFraction を追加してデフォ
Java 7 CMS GCの基本的な情報の整理 - nekop's blog
バッチ処理などスループット重視のアプリケーションはデフォルトのパラレルGCで良いが、Java EEアプリケーションサーバなどレスポンスタイム重視のものやHadoopなどのクラスタ系ソフトウェアで死活監視に引っ掛る系などのstop the worldをなるべく避けたいいわゆるサーバ系ソフトウェアを運用する場合には、UseConcMarkSweepGCを付与して停止時間の短いCMS GCを使う。その場合にCMSのチューニングに踏み込もうとするとなんだか難しい記述がいっぱいで若干困るので、簡単なガイドをメモとして書いておく。 対象バージョンは以下。 $ java -version java version "1.7.0_51" OpenJDK Runtime Environment (fedora-2.4.5.1.fc20-x86_64 u51-b31) OpenJDK 64-Bit Serve
第7回 HotSpot JVMではどのようにオブジェクトが移動するのか | gihyo.jp
1回目のマイナーGCまでの流れを把握する 前回は、HotSpot JVM（以下HotSpot）のヒープ構造を解説しました。今回は、HotSpot JVMの4つのヒープ領域がどのように使用されていくのかを見ていきましょう。 まず、アプリケーションがオブジェクトを作成すると、HotSpotはそのオブジェクトにEden領域を割り当てます。 図1 オブジェクトが生成されるとEden領域が割り当てられる アプリケーションが処理を実行していくと、オブジェクトがどんどん作成されていきます。その結果、Eden領域が次々と使用されていきます。 Eden領域がいっぱいになり、空き領域がなくなると、HotSpotはNew領域を対象にGCを行います。このGCは「マイナーGC」と呼ばれ、世代別GCで言う「若い世代のGC」になります。 このように、Eden領域で短命なオブジェクトを回収することで、ヒープを再利用できる
JVMのチューニング - ITエンジニアとして生きる
前回、JVMとGCのしくみ - ITエンジニアとして生きるでJVMとGCのしくみについて書いた。 今回はその続きということでJVMのチューニングについて書きたいと思う。 JVMチューニングって -Xms ・・・ ヒープ全体（New領域＋Old領域）の初期値 -Xmx ・・・ ヒープ全体（New領域＋Old領域）の最大値 くらいしか話題に上がらないし意識しないことが多い（気がする）。 でもホントはこれだけではダメで、前回のようにPermanent領域、New領域、Old領域を意識したチューニングが必要になる。 VMチューニングを考えるその前に・・・チューニングの話をする前にまずVMの起動モードについて話したいと思う。 VMには大きく以下２つの起動モードがあり、それぞれ以下のような特徴を持つ。 ◆クライアントVMモード 起動時間を短縮し、メモリサイズを縮小するように調整されている。 VM起動時
Garbage Collectionについてちょっと調べてみた - wyukawa's diary
HBaseのJuliet PauseをきっかけにしてGarbage Collection(以下GC)についてちょっと調べてみました。そういえば長年Javaでお仕事している割にはGCのこと全然知らなかった（汗 GCというのは不要になったメモリを回収することをいいますがそのアルゴリズムにはいくつかあって代表的なものとして以下の2つがあります。 Mark Sweep GC Coping GC Mark Sweep GCはオブジェクトをアプリケーションからたどっていってMarkしていきます。Markが無いのは使われていないオブジェクトなのでSweepします。メリットは実装が簡単なことでデメリットはメモリの断片化、フラグメンテーションが起きることです。 Coping GCはヒープ領域を2つに分けてオブジェクトをコピーしたり移動したりすることです。メリットはスループットが高いことやフラグメンテーション
『徹底解剖「G1GC」実装編（β版）』を公開しました！！ - I am Cruby!
全国数千人（GC本売上調べ）のGCファンのみなさま、おまたせいたしました。 『徹底解剖「G1GC」実装編（β版）』を以下のURLに公開しました！ 徹底解剖「G1GC」実装編（執筆中） （PDFやEPUB,mobiもリンク先から辿れます） なかなか面白い内容になったと思いますのでぜひぜひ読んでみてください！ β版と銘打っていますが、書きたい部分はすべて書いたつもりですので正式公開になっても内容が大きく変わる可能性は低いです。 ただ読者様から重大な指摘があったりすると困るのでとりあえず1ヶ月くらいはβ版とし公開させていただきます。 ぼちぼち書きながら休みながら結局完成にさせるのに半年もかかってしまいました…。 ページ数も140ページくらいいってしまったし…。 本書きは書き始めてからちゃんと終わらせることが一番大事なことのように思います。 いやー終わらせられてよかった（遠い目）。ツイートする
JavaのGCログを日付時刻で表示する - カフェイン中毒エンジニアの事件簿
こんなのを見て。 http://www.theserverlabs.com/blog/2010/05/26/human-readable-jvm-gc-timestamps/ まずは基本編。 -Xloggc: -Xloggc: タイムスタンプが付いたファイルにGCステータスのログを記録する -XX:+PrintGCDetails Print more details at garbage collection. Manageable. (Introduced in 1.4.0.) 次に問題のやつ。Oracleのサイトで資料が見つからない…。 -XX:+PrintGCDateStamps で試しにこんなのを設定すると、 -Xloggc:./gc.log -XX:+PrintGCDateStamps -XX:+PrintGCDetails こうなる。 2012-02-21T23:24:35.5
JavaVMのメモリ管理に関するまとめ（Javaヒープ、GC、ダンプ等） - ぺーぺーSEのブログ
本ブログはJava8（特にMetaspace）に対応していない。 下記にJava8以降に対応した記事を記載する（予定）。 blog.pepese.com JavaVMのメモリ領域について JavaVMが管理するメモリ領域について 階層1 階層2 階層3 説明 Javaヒープ JavaVM上で起動するJavaプログラムのリソースを管理する領域。New領域とOld領域で構成される。 ｌ" New領域 新規オブジェクトと閾値（-XX:MaxTenuringThreshold）未満のオブジェクトが配置される。（Young領域とも呼ばれる） ｌ ｌ" Eden領域 新規のオブジェクトが配置される。 ｌ ｌ" From領域 CopyGC(ScavengeGC、マイナーGC)が実行された際に、使用中のオブジェクトはここへコピーされる。（S0やS1とも呼ばれる） ｌ ｌー To領域 CopyGC(Scav
僕はJavaのWeakHashMapを勘違いしていたというメモ - 働かないプログラマのメモ帳
JavaにWeakHashMapというクラスがあって、僕はこれをvalueを弱参照で持てるHashMapだと思ってたんですけど、本当はkeyを弱参照で持つHashMapだったのでメモしておきます。 どういうことかって言うと、僕はこんなことを期待していたわけです。 Map<String, String> m = new WeakHashMap<String, String>(); String key = new String("hoge"); String value = new String("fuga"); m.put(key, value); System.out.println(m.containsKey("hoge")); // => true value = null; System.out.println(m.containsKey("hoge")); // => false
＠IT：Javaパフォーマンスチューニング 第3回
本記事は、HP-UX Developer Edgeに掲載された記事を株式会社アットマーク・アイティおよび本記事の筆者が独自の判断のもとに加筆・修正したものです。 今回は、Javaにおけるヒープ・メモリ管理の詳細を説明します。JVMのヒープ・メモリの中で、新しいオブジェクトと古いオブジェクトがどのように配置されるかを理解することで、ヒープ・メモリが有効に利用されているか否かを判断することができます。また、JVMが出力するガベージ・コレクションのログを解析し、オプションの指定によってヒープ・メモリのサイズを適切にチューニングする方法を紹介します。 Java ヒープ・メモリの構造 Javaにおけるガベージ・コレクションのメカニズムを理解するには、まずヒープ・メモリの構造を知っておく必要があります。 図1は、JVM におけるヒープ・メモリの構造を示したものです。この図が示すように、ヒープ・メモリの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Application Performance Monitoring | Splunk