Slide 1
<Insert Picture Here> Oracle Direct Seminar サポートエンジニアが語る WebLogic Serverトラブルシュートのノウハウ 日本オラクル株式会社 カスタマーサービス統括 アドバンストカスタマーサービス本部 Copyright© 2010, Oracle. All rights reserved. 2 アジェンダ • はじめに • 障害時に取得するWLSのログ情報 • Javaスレッドダンプの重要性 • 典型的なトラブルの事例とその解決方法 • Advanced Customer Servicesのご紹介 ・SQL Serverからの移行アセスメント ・MySQLからの移行相談 ・PostgreSQLからの移行相談 ・Accessからの移行アセスメント ・Oracle Database バージョンアップ支援 ・Oracle Developer/
Javaのスレッドダンプの読み方 - ablog
あなたとスレッドダンプ - スレッドダンプ入門 - この国では犬が が非常にわかりやすく、自分でブログエントリを書く必要はないが、Oracle Database や Linux の性能分析に携わる者の観点から Java のスレッドダンプについて整理してみた。具体的なスレッドダンプの分析方法はサポートエンジニアが語るWebLogic Serverトラブルシュートのノウハウがとてもわかりやすい。 WebLogic のスレッドダンプの見方については id:yamadamn さんの スレッドダンプから見るWebLogic Serverの世界 #javaee - yamadamnのはてな日記 がわかりやすい。 スレッドダンプとは Javaのスレッドのスナップショット。 取得した瞬間のJava仮想マシン(JVM)内に存在するスレッド（ID、名前、状態、タイプなど）とコールスタックを見ることができる。
Matthew Gilliard's blog || Better Containerized JVMs in JDK10
TL;DR The JDK team has committed to making Java a good citizen in a world of containers. JDK10 contains several changes to have the JVM and your apps respect container restrictions. JDK10 is due to be released in March 2018. This post is a counterpoint or followup to Jörg Schad’s recent post Nobody puts Java in a container. I would absolutely recommend reading that for its excellent summary of how
CMS GC おさらい - unnamed
この記事は 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 について比較的重要な点についてだけ簡単におさらいしたいと思います。 オプションに
Getting Started with the G1 Garbage Collector
Purpose This tutorial covers the basics of how to use the G1 garbage collector and how it can be used with the Hotspot JVM. You will learn how the G1 collector functions internally, the key command line switches for using G1, and options for logging its operation. Time to Complete Approximately 1 hour Introduction This OBE covers the basics of Java Virtual Machine(JVM) G1 Garbage Collection (GC) i
jcmd と既存ツールの対応 - unnamed
はじめに この記事はJava Advent Calendar 2016の 1 日目の記事です 先日の Java Casual #2) で jcmd について話してきました。 jcmd #javacasual from Yuji Kubota jcmd は Oracle 社のドキュメントでは推奨ツールとして扱われており、jps や jmap, jstat のような既存ツールは "Experimental" とされています。このため、既存ツールから jcmd への移行が進められる可能性があります。例えば Experimental であった jhat は Java 9 から削除されます。 Java 9 からの新機能を含めた jcmd の各種機能は上記スライドを見ていただくとして、ここでは jcmd でどのように既存ツール相当の機能が使えるかを紹介したいと思います jcmd とは jcmd はロー
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
恐怖の JVM 大量メモリ消費！メモリリークの謎を追え！！ - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、ミドルウェア開発チームの青木(@a_o_k_i_n_g)です。将来の夢は川口浩探検隊に入ることです。 先日、弊社のアプリケーションサーバーで大量にメモリを消費するという現象に遭遇しました。アクセス頻度の低いサーバーがメモリを大量消費するという謎深いものでした。 発生当初の状況はこんな感じです。 アプリケーションサーバーでは Jetty が稼働 現象が発生した JVM は 5GB 程度のメモリを消費しており、明らかに通常ではない量のメモリを消費している 複数台のサーバーで発生していたが、全てで発生したわけではない。 また、発生したサーバーはいずれもアクセス頻度が少ないサーバーだった。 ヒープ、パーマネント、スタック ひとまず、JVM でトラブルが発生した時は何はともあれヒープダンプとスレッドダンプを見るに限ります。各種情報の取得をインフラ部隊へ依頼し、得られたヒープを解析すると、
メモリリークトラブルシューティング記 – その4: リーク箇所を確認する色々な方法 – yusuke.blog
– その1: 自宅サーバがハング – その2: フリーズの原因はガベージコレクション – その3: 侍でヒープ使用量を確認 – その4: リーク箇所を確認する色々な方法 前回のエントリではOld 領域にオブジェクトが溢れていることを突きとめた経緯を書きました。 次は、ヒープ領域にどんなオブジェクトが溜まっているのか確認する必要があります。 リークしているオブジェクトを検出する方法はいくつかあり、それぞれ以下のような特徴があります。 1. プロファイラ リーク検出を行う上で一番有名な方法。 JVM に特殊なフックをかけ、オブジェクトの生成、GC 等の挙動を監視します。 アプリケーションを動作させながら増加してくオブジェクトだけを抽出したり、オブジェクト生成に至るスタックトレースを確認したりと様々な視点で VM を調査できるのが特徴です。 一般的にプロファイラを使うと VM のパフォーマンスが
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
Javaでヒープ領域を余らせたままOutOfMemoryErrorを出す方法 - 西尾泰和のはてなダイアリー
先日、こんな問題を見かけたのだけども、JavaのGCにはあまり詳しくないので答えがわからなかった。 OutOfMemoryErrorが発生しました。(中略)ヒープメモリは足りているようです。原因として何が考えられますか？ http://d.hatena.ne.jp/iad_otomamay/20130318/1363596244 なんでだろうなぁと思っていたところid:moriyoshiが「Permanent領域があふれたんじゃないの」と一言。「Permanent領域」で検索してみると、なるほど、そういうことなのかー。 というわけで早速それを再現させるコードを書いてみた。ヒープの大部分ががら空きなのにPermanent領域だけ99%になっているのがわかるかと思う。 Exception in thread "main" [Full GC [Tenured: 515K->515K(56896K
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
Kotlin 1.0 リリース: JVMとAndroid向けの実用的(Pragmatic)言語 | Post Blog
See discussions on Reddit and Hacker News Kotlin #とは? KotlinはJVMとAndroid向けのオブジェクト指向かつ関数型な実用的(Pragmatic)言語です。相互運用性、安全性、明瞭性、そしてツールサポートにフォーカスしています。 汎用言語であるKotlinはJavaが動作する場所であればサーバサイドアプリケーション、モバイルアプリケーション(Android)、デスクトップアプリケーションを含むどこでも動作します。以下のメジャーなツールやサービスに対応しています: IntelliJ IDEA、Android Studio、Eclipse Maven、Gradle、Ant Spring Boot (KotlinサポートがKotlin 1.0と同時にリリースされました!) GitHub、Slack、Minecraft Kotlinの焦点
「Java SE 6完全攻略」Garbage First GC
Javaがヒープの管理にGCを使用しているのは、読者の皆さんもご存じの通りです。GCの手法にはいろいろありますが、HotSpot VMが採用しているのが世代別GCです。今回は、世代別GCの概要と問題点を解説したうえで、これを解決するために導入されたGarbage First GCについて説明します。 世代別GCの概要と問題点 世代別GCは若いインスタンスと時間を経たインスタンスを別々の領域に配置し、管理する手法です。これは寿命の短いインスタンスほど多いという性質をベースにしています。 若いインスタンスが配置される領域をヤング領域、時間を経たインスタンスを配置する領域をオールド領域とよび、それぞれの領域で異なるGCの手法を使用します。つまり、ヤングとオールドという世代の異なる領域を、それぞれ異なるGCで管理するのが世代別GCというわけです。 ヤング領域には高速ですが漏れのあるGCを用います。
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
徹底解剖「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 謝辞 本書はスポンサーのみなさまの金銭的支援によって執筆されました。 スポンサーのみなさま あ
G1 GC おさらいと #jjug_ccc で発表した話 - unnamed
この記事は Java Advent Calendar 2015 の一日目の記事です。二年連続でトップバッターだ！ 先日の JJUG CCC 2015 Fall で G1 GC について話してきました。 去年の CMS GC と同じく結構遅めの時間帯＆裏番組に伝説の灰色ページ管理人・ひしだま伝道師が発表するなどの豪華な時間帯にも関わらず、165人規模の部屋がいっぱいに埋まるぐらいの盛況でした。聴講頂いた皆様ありがとうございました！ スライドは以下に公開しました。G1 GC の挙動から GC ログの読み方、どういうケースが厄介なのかを紹介しているので是非ご覧ください！ Garbage First Garbage Collection (G1 GC) #jjug_ccc #ccc_cd6 from Yuji Kubota アフターフォロー、またはちょっとした補足 極力、後から参照可能なように資料
Java8のHotSpotVMからPermanent領域が消えた理由とその影響 | ギークを目指して
今回も前回の記事につづき、Java8による変更点で未だあまり紹介されていないポイントを記事にしようと思う。 今回はJava8のHotSpotVMの話。Java8ではJEP122が取り込まれ、VMのメモリモデルが変更された。JEP122のタイトル「Remove the Permanent Generation」から想像できるとおり、Java8のHotSpotVMからは従来のPermanent領域が無くなった。 なぜ、こういった変更が行われたのだろうか？また、元々Permanent領域に格納されていた情報は何処にいってしまったのか？JVM付属のツールにどういった影響があるのか？ 今回の記事ではこの点をまとめていこうと思う。 なお、HotSpotVMのメモリモデルについて詳しくない方は、先にこちらの項番（「補足 – HotSpotVMのメモリ構造概説）を読んでいただくとスムーズに読み進められるだ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Application Performance Monitoring | Splunk
Java Magazine Vol.26