タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

javaとJavaとGCに関するdecoy2004のブックマーク (14)

  • SparkアプリケーションのためのJavaガベージコレクションのチューニングについて - TEPPEI STUDIO

    この記事は、インテルの SSG STOビッグデータテクノロジーグループのメンバーからDataBricksに寄稿されたブログを翻訳したものです。誤訳がありましたら、@teppei_tosaに御連絡ください。 Sparkは、その優れた性能、シンプルなインターフェイス、および分析や計算のための豊富なライブラリによって、幅広い業界で採用されてきています。ビッグデータエコシステムにおける多くのプロジェクトと同様に、Sparkは、Java仮想マシン(JVM)上で実行されます。Sparkはメモリに大量のデータを格納することにおいて、Javaのメモリ管理とガベージコレクション(GC)に大きく頼っています。また、プロジェクトTungstenなどの新たな取り組みは、将来のバージョンで、メモリ管理のさらなる簡素化と最適化を目指しています。しかし、今日時点でも、JavaのGCオプションとパラメータを理解しているユ

    SparkアプリケーションのためのJavaガベージコレクションのチューニングについて - TEPPEI STUDIO
  • OutOfMemoryError の調べ方 - Qiita

    Java 8 で、 Oracle の JVM を前提とした話です。 Java のメモリ管理 これを知っておかないと、 OOME が起こっても、メモリ内で何が起こっていて、どこを調査すべきで、どのように対処したらいいのかが判断できない。 なので、まずは、そもそも Java がどうやってメモリを管理しているのかを知る。 しかし、実際調べてみたら予想通りというかなんというか、量が多くなってしまった。 なので、個々の用語の説明は末尾の 用語集 に押し込めたので、ここではざっくりとした概要だけ記載する。 メモリの構造 超ざっくりとした、メモリ構造を表した図。 おおきく、ヒープ(Heap)領域とネイティブ(Native)領域の2つの領域がある。 ヒープは Java プログラムが使う領域で、プログラム上で生成したオブジェクトは、このヒープ領域に配置される。 一方、ネイティブ領域は JVM が動くのに必要

    OutOfMemoryError の調べ方 - Qiita
  • Garbage First Garbage Collection (G1 GC) #jjug_ccc #ccc_cd6

    * 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
  • 書籍「Javaパフォーマンス」を読んで - n-agetsumaの日記

    監訳者の@cero-tさんから頂きました。@cero-tさん、ありがとうございます。 Javaパフォーマンス 作者: Scott Oaks,アクロクエストテクノロジー株式会社(監訳),寺田佳央(監訳),牧野聡出版社/メーカー: オライリージャパン発売日: 2015/04/11メディア: 大型この商品を含むブログ (3件) を見るJavaトラブルシューティングに関する仕事に関わっていると、まだ切り分けができていない性能遅延の原因について、GCが疑われることが良くあります。『自動で動く』ことによるブラックボックス感によりGCは疑われやすくなっていると思います。 しかし、実際に色々な案件の解析を繰り返すと、性能遅延の要因は多種多様です。過去に遭遇した代表的なものには、GC以外にも以下のような遅延要因があります。 アプリケーションの不効率なロジック (ループ過多、オブジェクト生成過多) 過度なロ

    書籍「Javaパフォーマンス」を読んで - n-agetsumaの日記
  • Concurrent Mark-Sweep Garbage Collection #jjug_ccc

    Re-Introduction: Concurrent Mark-Sweep Garbage Collection @ Japan JUG Conference.

    Concurrent Mark-Sweep Garbage Collection #jjug_ccc
  • 「Java パフォーマンス」感想 - unnamed

    書の翻訳者の一人である@cero_tより献頂きました、ありがとうございます。というわけで一週間かけて読んでみた。 www.amazon.co.jp 今現在 Java で開発している人、特に運用者や試験者は間違いなく買っておくべきです。Javaに限らない一般的なパフォーマンスチューニングの考え方・観点から、Java アプリケーションにおいてボトルネックになりやすい GC や JIT の詳細な確認方法からチューニング方法が解説されている。特にすごいのが Java の世界のみならず、OS の世界まで触れている点。流石に OS の世界はここに書かれているのが全てではないけれど、Java アプリに関わる部分で問題になりやすい点は割と触れている。 JDK8 にも対応しており、今現在手に入る情報としては一番頼もしいと思う。4000 円程度でこの知識量が手に入るなら非常に安い。 お勧めの読み方 個人

    「Java パフォーマンス」感想 - unnamed
    decoy2004
    decoy2004 2015/04/20
    『Large Page や TLB キャッシュ率、オブジェクトのロックコストなどに一冊で言及した書籍』
  • 最強のJVMチューニング・ツール: GCログを可視化するGCViewerとリモート接続でプロファイリング可能なVisualVM

    まずは倍率を1000倍から5000倍に上げます。 Data Panelも一旦非表示にします。 さて、これを見ると、使用済みヒープと使用済みNew領域は比例しつつ一定の間隔で上下しています。 ここからは特異点は見えないので、一旦非表示にします。 イニシャル・マークレベル(黄色の線)も一定で、分析対象としづらいので非表示にします。 すっきりして少し見やすくなりました。 ここから、 最も時間がかかっているのはイニシャル・マーク イニシャル・マークは1分間に2回程度発生している ということが読み取れます。 イニシャル・マーク では、そもそも、コンカレントGCにおけるイニシャル・マークとは何なのでしょうか。 OracleのドキュメントのReviewing GC with the CMSによると、New領域から参照されているオブジェクトをマークするのだと。 Stop the Worldを伴い、マイナー

  • JavaVM監視・解析ツール HeapStatsを使ってみた | Casley Deep Innovations株式会社 技術ブログ

    こんにちは!SI部の満石です。 以前、仕事JRockit Flight Recorder(現在OracleJDKに付属しているJava Flight Recorderの元になったもの)を使ったことがあり、最近出てきたHeapStatsにも興味があって使ってみたのでご紹介します。 HeapStatsとは NTT OSSセンタが開発したOSS(Open Source Software)であり、HeapStatsの日語Wikiには以下のとおりに書かれています。 HeapStats とは、JavaVM のヒープやGC状況を監視する軽量なツールで、エラーの兆候を検知してSNMPのようなリアルタイムなアラートを発します。生成するログはかなり小さいもので、GUIツールで解析することができます。HeapStatsは、次の二つのプログラムで構成されます: エージェント(agent) – JavaVMの情

    JavaVM監視・解析ツール HeapStatsを使ってみた | Casley Deep Innovations株式会社 技術ブログ
  • 「Javaの鉱脈」でJVMオプションの記事を書きました | さにあらず

    WEB+DB PRESS の Vol.82 に、かなり気合いの入った JVM オプションの記事を書いたので、是非読んで頂きたい。 2014/8/23 発売ですので、既に購入頂いてる方も多いと思います。 電子書籍版もありますので物理的な媒体に興味がない方は PDF を買って下さい。 WEB+DB PRESS Vol.82@Gihyo Digital Publishing 今回の記事における対象読者について​ 今回の記事は、ターゲットとして Java に余り時間をコミットしていないけども便利なので JVM 上で動くアプリケーションをウッカリ運用している人をイメージしながら書きました。 例えば、OSS ものだと Hadoop や ZooKeeper、Lucene や Solr、商用製品だと Stash とか JIRA とか confluence とかそういうものですね。 僕の観測範囲だと、PHP

    「Javaの鉱脈」でJVMオプションの記事を書きました | さにあらず
  • JDK8からあるちょっと嬉しいGCログオプション - n-agetsumaの日記

    JDK8およびJDK8u20では、GCログに関連する2つの便利な機能が追加されている。いずれの機能も2014/8現在最新のJDK7 update 67 には含まれていないが、JDK7u80にてバックポートされる予定。 GCログにpidと日付を含める (JDK8より) JAVA_OPTS="$JAVA_OPTS -Xloggc:/var/log/wildfly/gc_%p_%t.log" => 実際のファイル名例 : gc_pid31455_2014-08-31_14-20-16.log.0GCログのフォーマットに%pを入れるとpid形式のプロセスIDが付与される。また%tを付与すると"_2014-08-31_14-20-16"のようにGCログファイルを作成した日付時分秒が追加される。かつてGCログはJavaを再起動すると同じファイルが上書きされて消えてしまうため、出力先を-Xloggc:g

    JDK8からあるちょっと嬉しいGCログオプション - n-agetsumaの日記
    decoy2004
    decoy2004 2014/09/01
    『JDK8よりGCログフォーマットに%p(pid)や%t(時間)が含められる。 JDK8u20よりjcmd GC.rotate_logでGCログローテションできる。JDK7u80 にバックポート予定』
  • jstatでJVMの統計情報を取得してGrowthForecastに投げて、グラフを作ってくれるスクリプト書いた - blog.nomadscafe.jp

    先日のJVM Operations Casual Talks、GCやメモリ管理についてまとまった発表や、モニタリングの手法などの話が聞けてよい会でした。 微妙に意識が高まっているところで、メモリ使用量やGCの統計情報を取得して、GrowthForecastでグラフを作ってくれるスクリプトを書きました。それPla、それFluentd系のやつです https://github.com/kazeburo/jstat2gf この元ネタは JVM Operation Casual Talksでのモリスさんの発表にでてきたグラフです。あれを簡単に作れるツールになります。 某JVMのプロセスに対して実行すると、こんな感じのグラフになります。上から「NEW領域」「OLD領域」「Permament領域」「1秒あたりのFull GCの回数」「1秒あたりのFull GCにかかった時間」となっています。 なんかF

    decoy2004
    decoy2004 2014/06/13
    『メモリ使用量やGCの統計情報を取得して、GrowthForecastでグラフを作ってくれるスクリプトを書きました。』
  • トラブルに備えるJVMオプション - n-agetsumaの日記

    以前の記事でトラブルが起きた後の初動対応を書いてみたが、いざトラブルに遭遇すると、まず再起動してからどうするか考えるケースが多いと感じている。しかし何も情報がないと『情報がない/再現方法が不明』などの理由からそのままお蔵入りになってしまう。今回はトラブルに事前に備えるために、地味だけど大切なJavaVMのオプションをまとめてみる。 GCログの出力とローテーション OutOfMemoryError発生時のヒープダンプ自動出力と出力パス設定 JavaVMクラッシュログの出力パス設定 JVMオプションの設定 (OpenJDK/OracleJDK) JavaVMにはGCおよびヒープメモリの状態をロギングする仕組みや、OufOfMemoryError時にヒープダンプを自動的に出力するような障害に備えて自動的に情報を出力する機能がある。おすすめのオプション*1は以下の通り。 java -Xms?g -

    トラブルに備えるJVMオプション - n-agetsumaの日記
  • JVM的な何か@JVM Operation Casual Talk

    Java Concurrency, A(nother) Peek Under the Hood [Java Day Tokyo 2016 3-C]

    JVM的な何か@JVM Operation Casual Talk
  • 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

    Java 7 CMS GCの基本的な情報の整理 - nekop's blog
  • 1