ふわっと JVM のヒープ領域監視について考える - ようへいの日々精進XP
ども、かっぱです。 はじめに Java アプリケーションを運用する上では避けて通れないであろうヒープ領域の監視についてフワッと考えてみた JVM には幾つか領域があるがヒープ領域に焦点を当てる 参考 http://www.whitemark.co.jp/tec/java/javaHeap.html http://www.whitemark.co.jp/tec/java/javagc.html http://d.hatena.ne.jp/ogin_s57/20120623/1340463194 http://d.hatena.ne.jp/ogin_s57/20120709/1341836704 https://docs.oracle.com/javase/jp/1.5.0/guide/management/agent.html http://chonaso.hatenablog.com/en
OutOfMemoryError の調べ方 - Qiita
OutOfMemoryError (以下 OOME)が起こったときにお手上げ状態にならないためにも、 Java のメモリ管理の仕組みとか、 OOME が起こったときの調査方法とかを調べる。 環境 OS Windows 7 > java -version java version "1.8.0_74" Java(TM) SE Runtime Environment (build 1.8.0_74-b02) Java HotSpot(TM) 64-Bit Server VM (build 25.74-b02, mixed mode) Java 8 で、 Oracle の JVM を前提とした話です。 Java のメモリ管理 これを知っておかないと、 OOME が起こっても、メモリ内で何が起こっていて、どこを調査すべきで、どのように対処したらいいのかが判断できない。 なので、まずは、そもそも J
G1GCのつかいどころメモ - nekop's blog
以下の環境とテストでCMSとG1GCを比較してみた。かなり急ぎでやったので間違っている可能性が多少ある。 16 cores, 32GB mem -Xms24g -Xmx24g 8 instances Infinispan 6.0.3.Final DIST cache, put 4GB data (1KB entry * 2M, 2GB data with one backup copy, 2GB * 2 = 4GB) CMS: -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=30 G1GC: -XX:+UseG1GC -XX:G1HeapRegionSize=16m -XX:InitiatingHeapOccupancyPercent=30 $ java -XX:+UseG1GC -XX:+PrintFlagsFinal
JVMオプション | Java | 技術メモ | TOYATAKU WEB
GCの種類と方式について [2013-08-23] GCとメモリ情報の出力 [2013-07-10] HotSpot関連 [2013-01-31] チューニング（性能改善）関連 [2016-07-14] new GC overhead limit exceeded [2013-01-31] -XXオプションについて、有効は「+」、無効は「-」と指定する。 自分がどのVMで起動しているか確認する場合は「java -version」コマンド。 Java VMのデフォルト値はJava HotSpot VM Optionsを参考に。 また、JVM は「クライアントVM」か「サーバVM」かを実行時に指定できる。 上記は指定しなかった場合、OSによってデフォルト値が異なるので、デフォルト値がどうなっているかは以下を参照する。 ・サーバークラスマシンの検出 GCの種類と方式について JVMでは、「Sca
まじめにJVMチューニング: 第3回 方針をたててパラメータをいじってみる
さて、前回までで、ログからフルGC（及び高負荷なコンカレントGC）が発生していることはわかりました。 で、このチューニングの目的は、GCによるマシンへの負担を低減することにあります。 まず「なぜGCが発生するのか？」と「jvmがどうやってメモリ管理を行っているのか？」を知らないとチューニングのしようがないのですが、これらについては、下記に詳しく記載されていたのでリンクをはっておきます。 GC発生の要因 http://www.atmarkit.co.jp/ait/articles/1005/13/news095.html HotSpot JVMのヒープ領域について http://gihyo.jp/dev/serial/01/jvm-arc/0007 で、これらをふまえて・・・ 一口にチューニングと言ってもいくつかのアプローチをとることができます。 とにかくOld領域がいっぱいにならないよう
第4回 3つのGCを使い分けて停止時間を最小にする | gihyo.jp
3つのGCを使い分けてCPUの使用率をコントロールする 「GCの時間が長くてシステムが反応してくれない……もっと短くならないかな？」 「GCが始まると、CPUが占有されちゃって、ほかのプロセスの動きが重くなるんだよね……」 「GCの停止時間が多少長くなってもいいから、ほかのプロセスへの影響を軽くできないかな？」 JVMを使用しているシステムでは、そんな話を耳にします。GCが起きていることまでは把握できているのですが、それからどうしたら良いのかわからないのです。 GCは、JVMの内部でGCスレッドがCPUに処理されることで行われています。そのため、GCが行われている間はCPUの使用率が増加してしまうのです。 GCをスレッドの観点で見ると、以下の3種類があります。 シリアルGC パラレルGC コンカレントGC これらの違いを把握すれば、CPUの使用率とアプリケーションの停止時間をコントロールす
GCオプション備忘録 - Qiita
チューニングのベースになるGCオプションの備忘録。 JDK6以上が対象で、デフォルトで設定されているものも明示的に指定。 動作設定 -server -d64 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=70 -XX:+DisableExplicitGC -XX:+UseCompressedOops -XX:+OptimizeStringConcat -XX:-UseGCOverheadLimit 64bitのサーバモードで起動。 コンカレントGCを使用。 サーバモードなのでCMSIncrementalModeは指定しない方がいい。 G1GCでもいいが、世代別GCの方
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
