侍 - ログ , スレッドダンプ解析ツール
"侍" とは 侍 はタブ表示できる GUI の tail ツールです。 標準出力・標準エラー出力をリダイレクトしたログファイルより Java のスレッドダンプのみを切り出して色分け表示したり、-verbosegcオプションによるログをグラフ表示したりできるため特に Java のトラブルシューティングに役立ちます。 システム要件 OS: JDK 1.4 以降の実行環境をサポートする Windows や Unix JDKは以下のページからダウンロードできます。 https://java.sun.com/j2se/1.5.0/ja/download.html 検証済みの解析対象JVM: JDK 1.3.x,JDK 1.4.x,JDK5.0 準拠の Apple/BEA/Sun/HP/IBM 製JVM 起動方法 侍のjarファイルはこちらよりダウンロードしていただけます。ダブルクリックするか、ターミ
OpenJDK/SystemTapのデバッグが有効な5つの事例
OpenJDK/SystemTapのデバッグが有効な5つの事例：Java on Linuxを鬼凄ネイティブデバッグ！（後篇）（1/3 ページ） OpenJDKとSystemTapは実案件で大活躍！ 前回の「OpenJDK＋SystemTapでトラブル解析はここまでできる！」ではOpenJDKとSystemTapの概要と、これらの組み合わせでできることを簡単なサンプルを交えながら説明しました。今回は実戦で使える事例ということで、以下の5つを具体的なスクリプトを含めながら説明します。スクリプトやソースコードはこちらからダウンロードできます。 GC動作状況の取得 特定メソッドのプロファイリング 特定メソッド実行時のスタックトレース取得 エンドポイントとのコネクション（ソケット）確認 競合するモニターオブジェクトの把握 なお、今回のサンプルはすべて、以下の環境で動作を確認しています。 OS：Red
OpenJDK＋SystemTapでトラブル解析はここまでできる！
Javaでデバッグしにくい3つの場面 Javaアプリケーションで構築されたシステムの障害や性能問題が発生した場合、大半はデバッガやプロファイラ、ミドルウェアやサードパーティが提供するツールを用いることで解析できてしまいます。 しかし、以下のような状況ではJavaの世界からのアプローチがしにくく、通常のデバッグノウハウが使えないことがあります。 プロセス再起動が許されないシステムでの情報取得がしたいとき 本番環境でしか発生せず、テスト環境でデバッグできない問題の場合 GC（ガベージ・コレクション）ログ（-Xloggcなど）のように、javaコマンド起動オプションを与えなければ取得できない情報が必要な場合 ソース変更が許されない場合に、特定状況下の情報を取得したいとき ある特定のメソッドなどが実行された瞬間のスレッドダンプやスタックトレースなどが必要な場合 ソースの変更ができない、環境の制約な
2010-08-09
Javaのデバッガを叩くライブラリとかないかなーと思って探していたのですが、やはり世の中にはあるものです。 http://youdebug.kenai.com/ Hudsonの作者でもある川口さんの作とのこと。さすがにツボをついてますねー。日本語での解説は以下が参考になります。 http://d.hatena.ne.jp/kkawa/20091108/p1 http://d.hatena.ne.jp/nobeans/20100216/1266341676 仕事に使えるかもしれないので暇なときに少しいじってみようと思います。 独習JavaScriptに増刷がかかったばかりですが、Seasar2徹底入門も増刷がかかるとのこと。 Seasar2徹底入門は今年の4月に出てから5ヶ月ほどでの増刷ですが、独習JavaScriptは増刷まで1年以上時間がかかったので、まさかこんなに早く増刷がかかるとは思
Java EEサーバからレスポンス返らず。何から調べる？
今回は、Webシステムの代表的な問題の1つとして、Java EE（J2EE）サーバのプロセスのハングアップが発生した場合を取り上げる。こういった場合、IT情シス・SE/プログラマがどういった流れで問題解決をしていくべきか。その手順について話をうかがったので、その内容を紹介する。 現象の見え方 今回は、以下の問題についての話だ。 問題解決への流れ 通常のプロセスハングアップが発生した場合、設定によっては、Java EEサーバのハングアップを検知して、自動的に障害資料採取およびサーバの再起動が実施される。しかし、このような設定を行っていない場合は、どうすればいいのだろうか。手動で障害資料を取得してから、サーバの再起動を行う必要がある。 プロセスハングアップ時に必要な障害資料は、OSの統計情報やJava EEサーバのログ・トレース、スレッドダンプだ。 スレッドダンプ 特に、スレッドダンプはハング
＠IT：低負荷なのにCPU使用率が100％
今回のワンポイント アプリケーション・サーバ上でアプリケーションを稼働中に、大きな負荷がかかっていないにもかかわらず、CPUの使用率が100％になってしまうときがある。こんなときに役立つのは、スレッドダンプだ。スレッドダンプは、実行中のスレッドスタックを取得できるため、そのとき何が起きているのかを解析するには最適である。スレッドダンプの結果、原因は、java.ioパッケージ内のクラスの使い方による問題であることが判明した。これは、一般にも多く作成されているであろうダウンロードやアップロード処理で見掛けるコードの一部でもある。今回は、トラブル発生時の原因究明に役立つスレッドダンプの解説と、問題の原因となったjava.ioパッケージの使い方が引き起こす、非常に特定しにくい事象について紹介する。 低負荷なのに、CPU使用率100％ アプリケーションに大きな負荷をかけていないのに、突然CPU使用率
Javaでデバッガがブレークポイントで止まらない - Yamashiro0217の日記
「Javaでデバッガがブレークポイントで止まらない」現象に僕の周りでハマってる人が割といました。まぁ、Eclipse以外でもそうだと思うのですが、とりあえずEclipse環境で。 で、twitterなどで教えてもらったのですが、 sun の jdk の 1.6.0_14 〜 15 で デバッグの問題 Java ™ Virtual Machine Tool Interface (JVM TI) のブレークポイントは、並列スカベンジガベージコレクタ (-XX:+UseParallelGC) または並列圧縮ガベージコレクタ (-XX:+UseParallelOldGC) が使用されている場合のみ信頼できます。 というリリースノートが。 http://java.sun.com/javase/ja/6/webnotes/6u15.html というわけで、デバッガ起動時にこのオプションを付けてあげれば
Emacs で Java アプリケーションをデバッグする—ありえるえりあ
Emacs で Java アプリケーションをソースレベルデバッグするのはいろいろ手を加えないとダメだと思っていたのですが、 Emacs 22.1 の gud.el と gdb-ui.el あたりを注意深く読んでいるとどうもそうでないということが分かり、実際にやってみたところ稚拙ではあるけど一応ソースレベルデバッグっぽいことができたので紹介しておきます。 GUD って何？ GUD (Grand Unified Debugger) は Emacs の統一フロントエンドデバッガで、現在のところ gdb, sdb, dbx, xdb, perldb, pdb, jdb をバックエンドとしてサポートしています。 その中でも gdb に関してはソースレベルデバッガに必要な機能（ブレイクポイントのマークを設置したりする）などが gdb-ui.el に記述されており、ウォッチやローカル変数ウィンドウなど、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
