Code-First Java 9 Tutorial // nipafx
So, Java 9 came out last year... What now? Where to get started? If that's what you're asking yourself, then you've come to the right place! This Java 9 tutorial is a condensation of all you need to know to find your way around the new release, to get you ready to explore it in more depth. Most topics begin with a block of code, so you can see right away how it works. We start with setup (includin
HeapStats/jp - IcedTea
1 ニュース OpenJDK8系の 8u262 以降の版とともに使用しないでください (2020/7/24) OpenJDK 8u262 は、素晴らしいことに、いくつかのディストリビューションで JDK Flight Recorder (JFR) が同梱されました。 しかし、残念なことに、HeapStats は 8u262 以降ではうまく動作しません。 8u262 以降でのJavaヒープの確認には、JFRの使用をお勧めします。 詳しくは、このページの下の実行環境セクションをご参照ください。 こちらもまたご覧ください。 http://icedtea.classpath.org/pipermail/heapstats/2020-July/002457.html {Exit|Crash}OnOutOfMemoryError を HeapStats と共に使わないでください(2019/7/25)
徹底解剖「G1GC」実装編（β版）
本書はOpenJDK7のG1GCの実装と、それに関連する技術を解説します。 目次 スポンサーのみなさま はじめに 1.準備 2.オブジェクト管理機能 3.アロケータ 4.ヒープ構造 5.オブジェクト構造 6.HotspotVMのスレッド管理 7.スレッドの排他制御 8.GCスレッド（並列編） 9.GCスレッド（並行編） 10.並行マーキング 11.退避 12.予測とスケジューリング 13.正確なGCへの道 14.ライトバリアのコスト さらに勉強したい人へ その他参考文献 以下から（ある時点で）最新のebookをダウンロードできます。 徹底解剖「G1GC」実装編-20120915.epub 徹底解剖「G1GC」実装編-20120914.mobi 徹底解剖「G1GC」実装編-20120914.pdf 謝辞 本書はスポンサーのみなさまの金銭的支援によって執筆されました。 スポンサーのみなさま あ
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
Java8のHotSpotVMからPermanent領域が消えた理由とその影響 | ギークを目指して
今回も前回の記事につづき、Java8による変更点で未だあまり紹介されていないポイントを記事にしようと思う。 今回はJava8のHotSpotVMの話。Java8ではJEP122が取り込まれ、VMのメモリモデルが変更された。JEP122のタイトル「Remove the Permanent Generation」から想像できるとおり、Java8のHotSpotVMからは従来のPermanent領域が無くなった。 なぜ、こういった変更が行われたのだろうか？また、元々Permanent領域に格納されていた情報は何処にいってしまったのか？JVM付属のツールにどういった影響があるのか？ 今回の記事ではこの点をまとめていこうと思う。 なお、HotSpotVMのメモリモデルについて詳しくない方は、先にこちらの項番（「補足 – HotSpotVMのメモリ構造概説）を読んでいただくとスムーズに読み進められるだ
Print All JVM Flags
Found an interesting JVM Flag : java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version It prints hundreds of various options, I never heard about before. It also prints default values, that helps diagnose JVM behaviors better. Another interesting flag is: -XX:+UnlockExperimentalVMOptions Does anyone knows of any documentation which explains each one of them ?
wall-climb » コンカレントGCの注意点
次? 代のサーバマシンによるシステムでは、CPUマルチコア化が進み、OSぜ 64bit化によってメモリも豊富に眩 むような大規模なものが一般的になるのではないでしょうか。このようなサーバ上ぜ Tomcatを起動させる場合、その? 富なリソースを生かしぜ Javaのヒープサイズ、GCチューニングを実施するのが一般的だと思゜ れます。ただし、このオプションを中途半端に? ? すると、逆にパフォーマンスを損なう可能性があることに注? しなければならないようです。 CPUマルチコアリソースを十分に活用する為ぜ GCチューニングパラメータに、「-XX:+UseParNewGC」「-XX:+UseConcMarkSweepGC」があります。前者ぜ GC処理をマルチCPUでパラレルに? 施するオプション、「-XX:ParallelGCThreads=n」と合゜ せてパラレル処理? (n)を指定出来ます。
JVMのオススメ起動オプション - oinume journal
なんか秘伝のタレみたいになってきたので後世のために共有。 前提 Webアプリケーションを想定 TomcatなりJettyなりがListenするポートは外部からはアクセスできない ※-Xms -Xmx -Xmn あたりは搭載しているメモリ容量によって変える、-XX:MaxPermSize -XX:PermSizeは384mあれば十分だと思うけどロードするクラスの数次第なので要調整。 NOW=`date "+%Y%m%d-%H%M%S"` JAVA_OPTS="-server -Xms2g -Xmx2g -Xmn1g -XX:MaxPermSize=384m -XX:PermSize=384m \ -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=85 -XX:MaxTenuringThreshold=32 \ Javaプログラマーなら習得しておきたい J
UseCompressedOops オプションのデフォルト値 - Quitada ブログ HAX
Java SE 6 な JVM の Oracle 実装（いわゆる元 Sun の Hotspot VM）Update 14 のタイミングで、64 ビット版で UseCompressedOops というオプションが使えるようになりました。本オプションの技術的概要については、下記サイトとか参照してください。 UseCompressedOops - Hotspot JVMの圧縮OOP ものすごく単純に言ったバージョンは、Update 14 のリリースノート参照。 http://java.sun.com/javase/ja/6/webnotes/6u14.html -XX:+UseCompressedOops オプションを使用すると、Java オブジェクトヒープのサイズが 32 ギガバイト未満の場合に、64 ビット JRE のパフォーマンスを向上させることができます。この場合、HotSpot はオブ
トラブルに備えるJVMオプション - n-agetsumaの日記
以前の記事でトラブルが起きた後の初動対応を書いてみたが、いざトラブルに遭遇すると、まず再起動してからどうするか考えるケースが多いと感じている。しかし何も情報がないと『情報がない/再現方法が不明』などの理由からそのままお蔵入りになってしまう。今回はトラブルに事前に備えるために、地味だけど大切なJavaVMのオプションをまとめてみる。 GCログの出力とローテーション OutOfMemoryError発生時のヒープダンプ自動出力と出力パス設定 JavaVMクラッシュログの出力パス設定 JVMオプションの設定 (OpenJDK/OracleJDK) JavaVMにはGCおよびヒープメモリの状態をロギングする仕組みや、OufOfMemoryError時にヒープダンプを自動的に出力するような障害に備えて自動的に情報を出力する機能がある。おすすめのオプション*1は以下の通り。 java -Xms?g -
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
CloudWatchのカスタムメトリクスでJavaVMのGC関連情報を取得 | DevelopersIO
JavaVMのGC情報を取得します 前回はLinuxOSのメモリー関連情報を取得して、CloudWatchに登録しました。今回は、JavaVMのガベージコレクション周りの情報をCloudWatchに登録したいと思います。 環境の構築 今回は、JavaVMのGCを見るためにTomcatをインストールします。また、JREではなくJDKを利用しますので必要なものをインストールします。CloudWatchコマンドラインツールは設定済みとします。詳しくは前回の記事をご覧ください。JREではなくJDKを入れる理由は、jpsコマンドとjstatコマンドを使うためです。これらのコマンドはプロセスIDなどを取得するためsudoで実行します。 $ sudo yum install java-1.6.0-openjdk-devel $ sudo alternatives --install /usr/bin/j
zabbixでhadoopクラスタのJVMを監視したい - Tech-Sketch
なぜzabbix？ Hadoop監視ツールとしてはAmazon Elastic MapReduceでの利用や、NTTデータが公表した 検証資料 で採用された Ganglia の方が有名ですが、日本ではユーザ会の活動も活発なzabbix を使って監視したい！という方のためのアプローチです。zabbixに強いTISの某I氏が作成したものを引き取ってJVM監視用に拡張しました。 zabbix-server-1.8.5に含まれているzabbix-templateにはjmxを使った定義も格納されているのですが、portの特定等少々面倒なようなので、新たに定義しなおしています。 監視のためにやったこと 基本的にはawkでJVMやリソース情報を取るスクリプト書き、zabbix-agentから呼び出しています。 こんな感じです。 ps auxww で取れる情報から、指定のプロセスを実行クラス名でgre
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
A Heap of Trouble: Managing Elasticsearch's Managed Heap
Understanding HotSpot JVM Performance with JITWatch
Oracle Blogs
IBM Developer
なにもわからないところから始めるJVMモニタリング
22.8. JVM Settings
Scala Performance Tuning Tips
