* 2015/12/01 12:40 修正 * P.65 の1段落目の表現を修正しました。(不要オブジェクトが閾値を上回る -> 生存オブジェクトが閾値を下回る) 表現だけ見ると内容は一緒なのですが、オプションで指定可能な閾値の意味を考慮すると修正前の文章は誤りでした。 Introduction of G1 GC at JJUG CCC 2015 Fall. http://www.java-users.jp/?page_id=2056
![Garbage First Garbage Collection (G1 GC) #jjug_ccc #ccc_cd6](https://cdn-ak-scissors.b.st-hatena.com/image/square/3f75a40136c87d61e85abe37fa9c0f4d6f8bd598/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fjjugccc2015fallg1gc-151128052053-lva1-app6891-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
JVMにチューニング項目は多々あれど、プロダクションで運用する際に予めおさえておきたい項目をまとめてみるエントリです。*1 勿論、OSもJVMもデフォルトである程度のパフォーマンスは発揮でき、計測を伴わないチューニングは悪手であることはよく知られています。 しかし、設定しておかないとパフォーマンスにそのまま影響すると分かるものを調べないのは裸で戦場に赴くようなものです。*2 どんな項目をどう変更すれば良いのか知っていることは重要な武器なのです。 なぜ調べるのか 今回、チューニングポイントを調べるにあたって、私のモチベーションはどこにあるのかを考えると、以下の要件を満たしたいということがあげられます。 アプリケーションとして求められる品質水準として動作する → 性能目標 異常時に事象を追うことができる ここでいう品質水準・異常とは、パフォーマンスが明らかに低い、アプリケーションがクラッシュす
-XX:G1HeapRegionSize=Nフラグを使い自分でサイズを指定することも可能。0はデフォルト値。 Nは2のべき乗である必要があり、それ以外の値が指定された場合は最も近い2のべき乗値へ切り下げられる。 ほとんどの場合、デフォルト値でもOKだが次のようなケースではチューニングを求められる。 例えばヒープの変動幅が大きい場合(-Xms4G -Xmx16G)、デフォルトではリージョンサイズは1MBとなり、ヒープが拡大さるとリージョン個数が16,000個となる。G1GCはリージョン個数が2,048程度を前提に設計されているためGC効率が悪くなる。このようなケースでは上記オプションの指定によりリージョン個数が2,048個前後になるようサイズ調整する。 G1GCのアルゴリズム G1では主に4つの処理が行われる。 young領域へのGC eden空間がいっぱいになるとyoung領域へのGCが発
この記事は、インテルの SSG STOビッグデータテクノロジーグループのメンバーからDataBricksに寄稿されたブログを翻訳したものです。誤訳がありましたら、@teppei_tosaに御連絡ください。 Sparkは、その優れた性能、シンプルなインターフェイス、および分析や計算のための豊富なライブラリによって、幅広い業界で採用されてきています。ビッグデータエコシステムにおける多くのプロジェクトと同様に、Sparkは、Java仮想マシン(JVM)上で実行されます。Sparkはメモリに大量のデータを格納することにおいて、Javaのメモリ管理とガベージコレクション(GC)に大きく頼っています。また、プロジェクトTungstenなどの新たな取り組みは、将来のバージョンで、メモリ管理のさらなる簡素化と最適化を目指しています。しかし、今日時点でも、JavaのGCオプションとパラメータを理解しているユ
JavaのWeb開発の開発後期になると性能試験や負荷試験を実施することになると思いますが、 そのフェーズになると色々な問題が起こることが多い。 今まで起きた問題と調査・解決方法をいくつかの回に分けて紹介しようと思います。 まずはメモリリーク。 長時間サーバを起動して運用していたり、負荷試験を実施するとメモリリークを起こすことがある。 ガベージコレクションのおさらい Javaのヒープは大きくnew領域(young領域)とold領域に分かれます。 new領域には生成されてすぐのオブジェクトが格納されてマイナーGCにて未使用になった際に開放されます。 マイナーGCを何度も繰り返されても開放されない(長く参照されている)オブジェクトは old領域へと移動され、こちらはメジャーGC(フルGC)で開放されます。(メジャーGCはnewとperm領域も開放。) もう少し細かく説明すると・・・ new領域は
先日職場でJVMの話をしてた。 ちょうどいい機会だからちょっとまとめたいと思う。 JVMの構成まずはJVMの構成について。JVMには3つの領域が存在する。 Permanent領域(非ヒープ領域) New領域(ヒープ領域) Old領域(ヒープ領域) Permanent領域にはJVMにロードされたクラスやメソッドの情報、New領域にはインスタンス化されたオブジェクトの情報、Old領域には寿命の長いオブジェクトの情報が管理される。(「寿命の長い」については後述のScavenge GCを参照。) Permanent領域は非ヒープ領域、New領域とOld領域はヒープ領域となる。 非ヒープ領域には基本的にGCは走らず、JVM起動時に静的な情報が管理される。(※) 一方、ヒープ領域はインスタンス化されたオブジェクト情報といった動的な情報が管理され、GC対象となる。 ※ユーザ定義のクラスローダーが存在する
前回、JVMとGCのしくみ - ITエンジニアとして生きるでJVMとGCのしくみについて書いた。 今回はその続きということでJVMのチューニングについて書きたいと思う。 JVMチューニングって -Xms ・・・ ヒープ全体(New領域+Old領域)の初期値 -Xmx ・・・ ヒープ全体(New領域+Old領域)の最大値 くらいしか話題に上がらないし意識しないことが多い(気がする)。 でもホントはこれだけではダメで、前回のようにPermanent領域、New領域、Old領域を意識したチューニングが必要になる。 VMチューニングを考えるその前に・・・チューニングの話をする前にまずVMの起動モードについて話したいと思う。 VMには大きく以下2つの起動モードがあり、それぞれ以下のような特徴を持つ。 ◆クライアントVMモード 起動時間を短縮し、メモリサイズを縮小するように調整されている。 VM起動時
Strings consume a lot of memory in any application. Especially the char[] containing the individual UTF-16 characters is contributing to most of the memory consumption of a JVM by each character eating up two bytes. It is not uncommon to find 30% of the memory consumed by Strings, because not only are Strings the best format to interact with humans, but also popular HTTP APIs use lots of Strings.
この記事は Java Advent Calendar 2014 の一日目の記事です。 先日の JJUG CCC 2014 Fall で CMS GC について話してきました。 結構遅めの時間帯にも関わらず、200人規模の部屋がいっぱいに埋まるぐらいの盛況振りで、みなさんGCにお困りなんだなあと実感しました。スライドは以下に公開しています。CMS GC の挙動から GC ログの読み方、どういうケースが厄介なのかを紹介しているので是非ご覧ください! Concurrent Mark-Sweep Garbage Collection #jjug_ccc from Yuji Kubota 嬉しいことにセッションの反応は良かったのですが、「遅めの時間帯で頭も疲れてるとガチ話辛い」という声もあったので、今回は CMS GC について比較的重要な点についてだけ簡単におさらいしたいと思います。 オプションに
This section describes how to adapt Garbage-First garbage collector (G1 GC) behavior in case it does not meet your requirements. The general recommendation is to use G1 with its default settings, eventually giving it a different pause-time goal and setting a maximum Java heap size by using -Xmx if desired. G1 defaults have been balanced differently than either of the other collectors. G1's goals i
Learn about how to adapt and tune the G1 GC for evaluation, analysis and performance. The Garbage First Garbage Collector (G1 GC) is the low-pause, server-style generational garbage collector for Java HotSpot VM. The G1 GC uses concurrent and parallel phases to achieve its target pause time and to maintain good throughput. When G1 GC determines that a garbage collection is necessary, it collects t
The Eclipse Memory Analyzer is a fast and feature-rich Java heap analyzer that helps you find memory leaks and reduce memory consumption. Use the Memory Analyzer to analyze productive heap dumps with hundreds of millions of objects, quickly calculate the retained sizes of objects, see who is preventing the Garbage Collector from collecting objects, run a report to automatically extract leak suspec
あるアプリケーションの作業にとって、スループットは最も重要なターゲットです。1つ例を挙げると、長時間実行されるバッチ処理のジョブです。ガベージコレクションが実行されている間、バッチジョブが時々1、2秒止まっても、ジョブ全体がすぐに完了すれば問題ありません。 人間が直接対話するアプリケーションから金融取引システムまで、実質的な他のすべての作業では、システムが1、2秒か、数ミリ秒以上反応しない場合、大変なことになり得ます。金融取引では、しばしば一貫した停止時間と引き換えに、スループットを犠牲にするだけの価値はあります。物理的に利用可能なメモリ量によって制限されるアプリケーションを持ったり、footprintを維持しなければならなかったりすることもあります。そのような場合、停止時間とスループットの面の両方で、パフォーマンスをあきらめなければなりません。 以下のトレードオフは度々起こります。 大部
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く