Javaプロセスの中でCPUを浪費しているスレッドを特定する - Qiita
概要 Javaプロセスの中でCPUを浪費しているスレッドを特定する方法を紹介します。Linuxだけでなく、Windowsでの方法も載せています。 前提条件 JDKがインストールされていること Linuxの場合 まずは、Linuxでの方法です。これと同じことがWindowsでも、できればいいわけです(後述します)。 (1) jpsコマンドで対象のJavaプロセスのIDを特定する $ top -n 1 -H -p 25800 top - 21:29:39 up 23:36, 3 users, load average: 1.66, 0.97, 0.52 Tasks: 31 total, 1 running, 30 sleeping, 0 stopped, 0 zombie Cpu(s): 2.9%us, 0.8%sy, 0.0%ni, 96.2%id, 0.1%wa, 0.0%hi, 0.0%
micrometer-registry-datadogを使ったらDatadogのJVMのメトリックがわかりやすくなった
以前書いた「 Spring Bootを1.5から2へマイグレーションするステップとポイント 」 にて、 Datadogに対してメトリックを送信するの仕組みを micrometer-registry-datadog に変更したのですが、 Javaアプリケーションのメトリック取得がいい感じだったので、今回はそれを紹介します。 Micrometerって何Micrometer はJVM上で動くアプリケーションのメトリックを取得するためのライブラリです。 各種モニタリングツールとの連携が可能で、2018/05時点では以下のモニタリングツールに対応しています。 AtlasDatadogGangliaGraphiteInfluxJMXNew RelicPrometheusSignalFxStatsDWavefrontこれらのモニタリングツールと対になるライブラリを使用することで、取得したメトリックを容易
JMX接続をひたすらやっていく | DevelopersIO
こんにちは。齋藤です。 今回のこの記事はJava アドベントカレンダー 2017 4日目に向けた記事です。 今日はJMXと格闘した記録をここに書いておきます。 今回は以下の内容について記述します。 ローカルのDockerコンテナ上に立ち上げたJVMに対して JMX接続する EC2上に立ち上げたJVMに対して JMX接続する EC2上のDockerコンテナ上に立ち上げたJVMに対して JMX接続する 今回JMX接続先に利用するのはElasticsearchです。 やっていきます。 ローカルのDockerコンテナ上に立ち上げたJVMに対して JMX接続する まずは手始めに、簡単なところから攻めていきます。 次のコマンドでElasticsearchを起動します。 docker run -d -it -e "ES_JAVA_OPTS= -Djava.rmi.server.hostname=127.
ふわっと 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
JConsole の使用
jconsole の使用 jconsole は、JMX に準拠した監視ツールです。Java 仮想マシンの広範な JMX 機能を使用して、Java プラットフォームで実行されるアプリケーションのパフォーマンスとリソース消費に関する情報を提供します。 jconsole の起動 jconsole インタフェース 概要情報の表示 メモリ消費の監視 スレッドの使用の監視 クラスのロードの監視 MBean の監視と管理 VM 情報の表示 jconsole の起動 jconsole 実行可能ファイルは、JDK_HOME/bin にあります。ここで JDK_HOME は、JDK がインストールされているディレクトリです。このディレクトリがシステムのパスにあれば、コマンド (シェル) プロンプトで jconsole と入力するだけで、このツールを起動できます。それ以外の場合は、実行ファイルへのフルパスを入力
あなたの知らないJDKの便利ツールたち
「Java News.jp（Javaに関する最新ニュース）」の安藤幸央氏が、CoolなプログラミングのためのノウハウやTIPS、筆者の経験などを「Rundown」（駆け足の要点説明）でお届けします（編集部） 標準JDKに含まれる便利なツール 読者の皆さんは、最近のJDK（Java SE）に、開発やデバッグに便利な新しいツールが含まれていることをご存じでしょうか？ 古くからのJava開発者は、古い時代のJDKのツールしか知らず、一方で新しいJava開発者はEclipse/NetBeansなどの統合開発環境に慣れてしまい、細かなコマンドツールを直に使う状況が減ってきているかもしれません。 そこで今回は、最近のJava SE 6含めて比較的新しいと思われるツールを以下の5種類に分けて紹介します。 プロファイリング トラブルシューティング／情報取得 監視 配備／補助 スクリプティング 「こんなツー
恐怖の JVM 大量メモリ消費！メモリリークの謎を追え！！ - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、ミドルウェア開発チームの青木(@a_o_k_i_n_g)です。将来の夢は川口浩探検隊に入ることです。 先日、弊社のアプリケーションサーバーで大量にメモリを消費するという現象に遭遇しました。アクセス頻度の低いサーバーがメモリを大量消費するという謎深いものでした。 発生当初の状況はこんな感じです。 アプリケーションサーバーでは Jetty が稼働 現象が発生した JVM は 5GB 程度のメモリを消費しており、明らかに通常ではない量のメモリを消費している 複数台のサーバーで発生していたが、全てで発生したわけではない。 また、発生したサーバーはいずれもアクセス頻度が少ないサーバーだった。 ヒープ、パーマネント、スタック ひとまず、JVM でトラブルが発生した時は何はともあれヒープダンプとスレッドダンプを見るに限ります。各種情報の取得をインフラ部隊へ依頼し、得られたヒープを解析すると、
Java™ 7でのガーベジコレクションの選択
Java 7のガーベジコレクションの入り口 Java 7のガーベジコレクションの仕様や実装を調べるなら、次の2つが入り口となるでしょう。 Java Garbage Collection Basics (日本語訳なし) Getting Started with the G1 Garbage Collector (拙者の日本語訳) Java 7でガーベジコレクションを選択する方法(6種類) Java 7ではエルゴノミクス機能により、自動的にガーベジコレクション(GC)を決定します。 エルゴノミクス機能による決定を無効にして自分でGCを選択したい場合、次の6種類のオプションの指定方法があります。 -XX:+UseSerialGC -XX:+UseParallelGC -XX:+UseParallelGC -XX:+UseParallelOldGC -XX:+UseConcMarkSweepGC
実行中のJavaアプリケーションの拡張設定を確認／変更する - CLOVER🍀
jinfoというJDKに付属しているコマンドラインツールを使用すると、Javaの起動オプションやシステムプロパティを確認できたり、「-XX」ではじまる一部の値については実行中に変更できるようです。 詳しい説明は以下に書いてありますが、jstackやjmapなどと同様、使用するには対象のJavaVMのPIDが必要です。 http://java.sun.com/javase/ja/6/docs/ja/technotes/tools/share/jinfo.html 例えば、以下のようなちょっとわざとらしいオプション指定でJavaアプリを起動します。 $ java -Xmx512M -XX:+UseParallelGC -XX:+UseParallelOldGC -XX:ParallelGCThreads=2 -XX:+PrintGCTimeStamps -XX:+PrintGC -XX:+Pr
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の方
JVMのチューニング - ITエンジニアとして生きる
前回、JVMとGCのしくみ - ITエンジニアとして生きるでJVMとGCのしくみについて書いた。 今回はその続きということでJVMのチューニングについて書きたいと思う。 JVMチューニングって -Xms ・・・ ヒープ全体（New領域＋Old領域）の初期値 -Xmx ・・・ ヒープ全体（New領域＋Old領域）の最大値 くらいしか話題に上がらないし意識しないことが多い（気がする）。 でもホントはこれだけではダメで、前回のようにPermanent領域、New領域、Old領域を意識したチューニングが必要になる。 VMチューニングを考えるその前に・・・チューニングの話をする前にまずVMの起動モードについて話したいと思う。 VMには大きく以下２つの起動モードがあり、それぞれ以下のような特徴を持つ。 ◆クライアントVMモード 起動時間を短縮し、メモリサイズを縮小するように調整されている。 VM起動時
＠IT：Javaパフォーマンスチューニング 第3回
本記事は、HP-UX Developer Edgeに掲載された記事を株式会社アットマーク・アイティおよび本記事の筆者が独自の判断のもとに加筆・修正したものです。 今回は、Javaにおけるヒープ・メモリ管理の詳細を説明します。JVMのヒープ・メモリの中で、新しいオブジェクトと古いオブジェクトがどのように配置されるかを理解することで、ヒープ・メモリが有効に利用されているか否かを判断することができます。また、JVMが出力するガベージ・コレクションのログを解析し、オプションの指定によってヒープ・メモリのサイズを適切にチューニングする方法を紹介します。 Java ヒープ・メモリの構造 Javaにおけるガベージ・コレクションのメカニズムを理解するには、まずヒープ・メモリの構造を知っておく必要があります。 図1は、JVM におけるヒープ・メモリの構造を示したものです。この図が示すように、ヒープ・メモリの
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
