全般
Oracle JRockit Mission Control
モニタおよびチューニング
機能
トラブルシューティング
タイム ゾーンの更新
詳細情報
全般
Java 仮想マシンとは何ですか?
Java 仮想マシン仕様では次のように説明されています。
「Java 仮想マシンは Java および Java 2 プラットフォームの基礎であり、ハードウェアやオペレーティング システムからの独立性、小さいサイズのコンパイル済みコード、悪意あるプログラムからのユーザの保護などを実現する技術を構成するものです。」
JVM は Java アプリケーションのコードを変換して実行するプログラムであり、.class ファイルに格納されている Java バイトコードを、ユーザが実際に Java プログラムの実行に使用するオペレーティング システムまたはプロセッサに固有のネイティブ コードに変換します。そのため、さまざまなオペレーティング システム/プロセッサの組み合わせに対応する各種の JVM が用意されています。JRockit JVM をサポートするオペレーティング システム/プロセッサーについては、「サポート対象のコンフィグレーション」を参照してください。
Sun JVM と JRockit JVM の違いは何ですか?
最もよく知られた JVM は Sun の実装です。Sun JVM は HotSpot と呼ばれます。Sun JVM は、Sun の Java Development Kit (JDK) および Java Runtime Environment (JRE) に付属しています。
JRockit JVM は、サーバサイド アプリケーションに向けて、信頼性とパフォーマンスのために最適化されています。これを実現するために、JRockit JVM では、コード生成、ホット スポットの検出、コードの最適化、高度なガベージ コレクション アルゴリズム、オペレーティング システムとの緊密な統合などの技術を使用しています。
JRockit JVM ではアプリケーションを異なる方法で記述する必要がありますか?
いいえ。他の JVM でも JRockit JVM でも、アプリケーションを記述する方法は基本的に同じです。ただし、JRockit JVM 上で適切に動作するように、アプリケーションを適切に設計および実装してください。推奨されるコーディングの方法については、『Java アプリケーションの開発』を参照してください。
JRockit JVM クラス ライブラリは、Sun に対応していますか?
はい、JRockit JVM クラス ライブラリは Sun クラス ライブラリと完全に対応します。
JRockit JVM をどのプラットフォーム上で実行しますか?
サポート対象のプラットフォーム ドキュメントには、JRockit JVM がサポートするすべてのプラットフォームのリストがあります。
JRockit JVM は、Java Web Start および Java Plug-in をサポートしますか?
いいえ。この機能は JRockit JVM の R26.2 バージョンから削除されました。
Sun JVM から JRockit JVM に移行する方法は何ですか?
JRockit JVM への移行に関する情報については、診断ガイドの JRockit JVM へのアプリケーションの移行を参照してください。
JRockit JVM 上で実行しているかどうかがわかりません。デフォルトで、JRockit JVM 上で実行しているかどうかを確認するにはどのようにすればよいでしょうか?
次のコマンドを実行します。
java -version
このコマンドでは Java のバージョンを検証します。Java のバージョンが JRockit JVM ではない場合は、JVM のパスより前の位置に JRockit JVM があることを確認してください。Windows 上でいくつかの JVM が windows システム フォルダ (C:\Windows\System32) にインストールされているのは、JRockit JVM はシステム フォルダより前のパスにあることを意味します。たとえば、
set PATH="D:\Program Files\bea\jrockit90_150_04\bin";%PATH%
J2SE 1.3.1 上でビルドされた BEA JRockit 7.0 を使用している場合に、この J2SE バージョンがサポートされなくなりました。どうすればよいでしょうか?
JRockit JVM を JRockit JDK 1.4.2 または 5.0 の最新版にアップグレードすることをお勧めします。サポート対象の J2SE にビルドされているだけではなく、どちらの JRockit のバージョンとも優れたパフォーマンスおよびより堅牢な機能を提供します。既存の JVM をこれらのいずれかのバージョンに置き換え、アプリケーションに変更を加えないまたは最小限の変更を行うことを考慮すると、JRockit JVM は以下のものを提供します。
- パフォーマンスの改善
- 起動時間の短縮化
-Xdebug モードの大幅な改良
JRockit JVM のいずれかの最新版へのアップグレードに関する指示については、『アップグレード ガイド』を参照してください。
公表されているベンチマークの数字はどこにありますか?
Standard Performance Evaluation Corporation のサイトに、関連する最新のベンチマーク データがあります。
Oracle JRockit Mission Control
「Could not create the Java virtual machine.」というエラー メッセージが表示されます。どうすればよいでしょうか?
設定した起動オプションのスペルを確認してください。それでも JVM を起動できない場合は、『コマンドライン リファレンス』で起動オプションを調べてください。
-Xmanagement を使用した際に「Error: Password file not found」というエラー メッセージが表示されます。どうすればよいでしょうか?
管理エージェントは、セキュリティを明示的に無効にするか、またはコンフィグレーションを行ってセキュリティを有効にする必要があります。詳細については、「-Xmanagement」を参照してください。
JRA 記録を作成するにはどうすればよいでしょうか?
JRockit Runtime Analyzer (JRA) 記録を使用して、JRockit JVM のパフォーマンスを設定した時間で調査することができます。ツールの使用方法については、JRockit Runtime Analyzer の使い方を参照してください。
注意 : 実行中のアプリケーションをモニタするにはどうすればよいでしょうか? に記載したとおり、JRA は Oracle JRockit Mission Control の一部になり、特別なライセンスが必要になっています。このツールに関するドキュメントはオンライン ヘルプとして含まれています。適切なライセンスを取得するには、http://dev2dev.bea.com/jrockit/tools.html を参照してください。
モニタおよびチューニング
Oracle JRockit Mission Control を使用して実行中のアプリケーションをモニタするにはどうすればよいでしょうか?
Oracle JRockit Mission Control は以下の機能で構成されます。
- Management Console : このツールを使用して複数 (1 つ) の JRockit JVM インスタンスをモニタと管理することができます。このツールを使って、メモリ、CPU 使用状況、その他の実行時メトリックに関する実データを取得し、表示できます。詳細については、Management Console の使い方を参照してください。
- JRockit Runtime Analyzer : このツールは、いわばオンデマンドの「フライト レコーダー」であり、JVM と JVM で実行されているアプリケーションの詳細な記録を生成します。記録されたプロファイルは、後から JRA ツールを使ってオフラインで分析することができます。詳細については、JRockit Runtime Analyzer の使い方を参照してください。
- Memory Leak Detector : このツールは、Java アプリケーションのメモリ リークの原因を突き止めるために使用します。JRockit Memory Leak Detector の傾向分析により、進行の遅いリークを発見します。Memory Leak Detector には詳細なヒープの統計 (リークしているオブジェクトを指し示すタイプとインスタンスを含む)、割り当てられている場所が表示され、メモリ リークの原因をすばやく絞り込むことができます。詳細については、Memory Leak Detector の使い方を参照してください。
Oracle JRockit Mission Control の一般の情報については、「Oracle JRockit Mission Control の概要」を参照してください。
また、JRockit JDK 5.0 とその以降のバージョンは、Java 管理標準を完全にサポートします。つまり、JMX を使用する任意のサード パティ 管理ツールを使用して、JRockit JVM のプロセスをモニタおよび管理することができます。
JRockit JVM のパフォーマンスをチューニングするためのコマンド ライン オプションは何ですか?
JRockit JVM のチューニングに関する基本的な情報については、Oracle JRockit JVM 診断ガイドの JRockit JVM チューニングの初歩を参照してください。
アプリケーションでどのガベージ コレクション アルゴリズムを使用するべきでしょうか?
ほとんどの場合は、すでにデフォルトの動的 (-Xgcprio:throughput) ガベージ コレクタを使用するように設定されているので、ガベージ コレクタを設定する必要はありません。ただし、アプリケーションによっては、休止時間の短縮が要求されるなど、アプリケーション固有の要件を考慮することが必要な場合もあります。その場合は、そうしたニーズに合ったガベージ コレクタを設定するとアプリケーションにとって有利でしょう。『Oracle JRockit JVM 診断ガイド』の「メモリ管理システムのチューニング」を参照してください。
機能
JRockit JVM は、PAE on Windows をサポートしますか?
PAE (Physical Address Extension) は、物理メモリをプロセスの仮想メモリ アドレス空間にマップすることを可能にします。一度にマップできるのは 2GB だけです (/3GB オプションを指定した場合は 3GB)。つまり、物理アドレス空間のさまざまな部分をマップするためには、仮想アドレス空間を再利用する必要があります。したがって、それ以上大きなメモリを通常のポインタで単純にアドレッシングすることはできません。この機能は、通常の Java ヒープではそれほど効果を発揮しません。通常の Java ヒープでは、32 ビットのポインタを使ってオブジェクトを参照し、常に仮想アドレス空間内の全ヒープを必要とするからです。
PAE はマッピングとメモリ アクセスを共同で制御できるアプリケーションで効果を発揮します。PAE は現時点では Java にあまり適していません。とはいえ、ネイティブのデータベース ドライバなら、データのキャッシュに PAE を使用することも考えられます。これを実現したい場合は、どうやって実現するかをいろいろなデータベース ベンダと相談するとよいでしょう。JNI を使ってネイティブ データベース API の上に独自の「DB アクセス レイヤ」を置くことで、カスタム キャッシュを作成するという方法もあるでしょう。
豊富な物理メモリを利用する方法としては、このほかに複数の Java プロセスを使用するというやり方もあります (Windows の各プロセスはプライベートなアドレス空間用に 2GB の物理メモリを取得できます)。
大きな Java ヒープが必要とする場合、JRockit JVM の64-ビット インプリメントを使用する必要があります。つまり、64-bit Xeon/AMD64 の Itanium version またはネイティブ Windows x64 version を使用する必要があります。.
JRockit JVM は、スレッドの優先順位をサポートしますか?
はい、JRockit JVM は Windows (IA32 および Itanium) 上のスレッド プロパティをサポートします。Linux または Solaris 上にサポートしません。
IA32 または Itanium Windows を実行している場合は、フラグ -XXusethreadpriorities を渡すことで優先順位変更要求を無視しないように JVM をコンフィグレーションできます。ただし、このフラグはすべてのプラットフォームで有効であるにもかかわらず、Windows でしか意味を持ちません。
優先順位変更要求はデフォルトでは無視されます。なぜなら、優先順位変更要求が不適切に適用された場合、アプリケーションの動作は変更前より悪くなるからです。あるスレッドに設定した優先順位が高すぎる場合、そのスレッドはリソースを過剰に消費することになり、パフォーマンスに深刻な影響を及ぼします。それに対し、設定した優先順位が低すぎると、優先順位の逆転が起こるおそれがあります。優先順位の逆転が起きると、優先順位の高いスレッドは優先順位の低いスレッドによるロックを待つので、いつまでも実行されず、その一方で、優先順位の高いスレッドがすべての CPU 時間を獲得するので、優先順位の低いスレッドにはロックを解除する機会がいつまでも与えられない、という状況が生じます。そのため、優先順位を設定したり使用したりするのは熟練プログラマに限るべきです。
トラブルシューティング
Java アプリケーションが JRockit JVM 上で動作しません。どこに問題があるのでしょうか?
JRockit JVM 上でのアプリケーションの実行に関する問題の多くは、誤った環境変数または非標準の起動オプションが原因です。まず、環境変数が正しく設定されていることを確認してください。JAVA_HOME 環境変数が、JRockit JVM をインストールしたディレクトリに正しく設定されていること、および、PATH 環境変数の設定において、いずれかのバージョンの java.exe が格納されている可能性のあるすべてのディレクトリより前の位置に %JAVA_HOME%\bin が記述されていることを確認してください。アプリケーションを Windows サービスとして実行する場合は、これらの環境変数をシステム全体で設定していることが重要です。次の手順に従います。
- [スタート] メニューを開いて、[設定｜コントロール パネル｜システム] を選択します。
- [詳細] タブを選択します。
- [環境変数] をクリックします。
システム全体の環境変数を設定するには、このダイアログ ボックスの下部の [システム環境変数] で編集する必要があります。
アプリケーションをスクリプトから起動することがよくあります。起動スクリプトに java に対する非標準の起動オプションが含まれていないことを確認してください。標準および非標準オプションの詳細については、『コマンドライン リファレンス』を参照してください。
JRockit JVM が不意にクラッシュしました。どうすればよいでしょうか?
診断およびトラブル クラッシュについては、JRockit JVM クラッシュのトラブル シューテングを参照してください。
JRockit JVM がフリーズし、応答しません。どうすればよいでしょうか?
フリーズした JRockit JVM の診断およびトラブル シューテングについては、「Oracle JRockit JVM がフリーズする」を参照してください。
JRockit JVM の起動に時間がかかります。どうすればよいでしょうか?
Java プログラムは Java コンパイラによってバイトコードにコンパイルされます。Sun JVM などの多くの JVM は、このバイトコードを実行するたびに解釈します。一方、JRockit JVM ではコード生成技術を使用して、バイトコードからネイティブ マシン コードを生成します。これは Just-In-Time (JIT) コンパイルとも呼ばれます。このコード生成手順では、実行の前の初期時間が長くなります。通常、それ以降のコードの実行速度は、バイトコードを解釈する場合よりも速くなります。JRockit JVM は、一般に長時間にわたって動作するサーバ アプリケーションに向けて最適化されています。時間の経過と共にコード生成のパフォーマンス上の利点を比較すると、初期時間がかかるというデメリットは取るに足りないものになります。
起動に時間がかかる場合の診断およびトラブル シューテングについては、「Oracle JRockit JVM の起動が遅い」を参照してください。
Java アプリケーションのスループットが低くなります。どうすればよいでしょうか?
パフォーマンス低下 (低いスループット) を診断し、JVM のチューニングによってトラブルシューティングする方法については、「アプリケーションのスループットを向上させるチューニング」を参照してください。
JRockit JVM の応答時間が長くかかります。どうすればよいでしょうか?
長い応答時間 (休止時間) を診断し、JVM のチューニングによってトラブルシューティングする方法については、個々のトランザクションの速度を高めるチューニングを参照してください。
JRockit JVM のパフォーマンスが長期的に低下します。どうすればよいでしょうか?
パフォーマンス低下のトラブル シューテングについては、「Oracle JRockit JVM のパフォーマンスが長期的に低下します。」を参照してください。
JRockit JVM 上でアプリケーションを実行するときはランダムにバグが発生し、Sun JVM 上で実行するときにはバグは発生しません。原因は何ですか?
アプリケーションで同期化のバグが発生している可能性があります。JVM を切り替えるときにそのようなバグが現れるのは珍しいことではありません。JVM 仕様と Java 言語仕様では、最適化の余地が多く残されており、最適化によって、共有データへの同期化されないアクセスや、異なる JVM 上での異なる動作が引き起こされることがあります。
詳細については、http://java.sun.com/docs/books/jls/second_edition/html/memory.doc.html および http://java.sun.com/docs/books/vmspec/2nd-edition/html/Threads.doc.html を参照してください。
JRockit JVM 上で実行するときに、IllegalAccessError、ClassFormatError、IncompatibleClassChangeError またはその他の LinkageError 例外が発生します。Sun JVM 上で実行するときに発生しません。原因は何ですか?
検証では、クラスまたはインタフェースのバイナリ表現が構造的に正しいことを確認します。たとえば、すべての命令に有効なオペレーション コードがあること、各分岐命令が、他の命令の途中ではなく、命令の開始点に分岐していること、どのメソッドにも構造的に正しいシグネチャがあること、すべての命令が Java プログラミング言語の型の規定に従っていることなどをチェックします。
検証中にエラーが発生すると、クラスの検証を引き起こしたプログラム内のポイントでリンケージ エラーが送出されます。その場合には、たとえば次のようなメッセージが表示されます。
Using JTidy throws IllegalAccessError
Apache Software Foundation の JTidy の初期のバージョンでは、コンパイラは外部のクラスに属しているプライベート変数への参照を誤ってインライン処理していました。JRockit JVM は Sun JVM よりも厳密な検証を行うため、例外が送出されました。古い Tidy.jar は、正しくコンパイルされる新しいバージョンに置き換える必要があります。
JRockit JVM は、Oracle WebLogic Server が開発モードで実行しているときに遅くなります。原因はなんですか?
WebLogic Server を開発モードで起動する場合、JRockit JVM はデフォルトで -Xdebug オプション付きで起動されます。このため JRockit JVM の実行に若干のオーバーヘッドが伴います。
JRockit JVM の実行時に、コンソールから JRockit に接続しようとした場合や、プログラムが CPU ロード カウンタにアクセスしようとした場合に、NotAvailableException が発生することがあります。
プロセス カウンタが初期化されないことが時々あります。これは、Windows のセキュリティ設定において、Performance Data Helper (PDH。オペレーティング システムからパフォーマンスの指標を取得する Windows API) プロセス カウンタを読み取れない場合、または何らかの理由により PDH プロセス カウンタが無効になっている場合にのみ発生します。この状態では、プロセス カウンタを読み取ってエラーを送出することができません。次のメッセージが表示されます。
[JRockit] WARNING: Could not initialize the virtualbytes counter, some functionality in jrockit.management.Memory will not be available. Message was: failed to createcounter query. String was: (null)¥Virtual Bytes
[JRockit] WARNING: Could not initialize the JVM process load counter, CPU load generated by the JVM will not be available. Message was: failed to createcounter query. String was: (null)¥% Processor Time
プロセス カウンタがオフになる理由は不明ですが、このような状況に遭遇した場合は、以下のサイトの指示に従ってプロセス カウンタをオンに戻してください。http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/exctrlst-o.asp。それでも問題を解決できない場合は、セキュリティ設定をチェックして、JVM プロセスを実行しているのと同じユーザとして Windows の perfmon ツールを使用し、そのパフォーマンス カウンタを読み取ることができるかどうかを確認してください。
Runtime.exec を実行しているときにファイル オープン エラーが多発するのはなぜですか?
Runtime.exec() を使用すると、見えないところでネイティブ リソースのコミットが行われ、その結果 IOException が発生することがあります。
このエラー メッセージの原因は、Runtime.exec() で stdin、stdout、stderr の各ストリームのためにファイル ハンドルが使われることにあります。これらのストリームは本来ならオブジェクトのファイナライザを通じて処理されます。ただし、Runtime.exec() の呼び出し頻度が非常に高いと、たいてい JRockit ガベージ コレクションをトリガする前にネィテイブ ファイルのハンドルがなくなってしまいます。到達可能でないファイナライズ候補のプロセス オブジェクトやストリーム ハンドルを JVM が見つけるにはガベージ コレクションが必要です。この問題はガベージ コレクションの頻度が低い場合 (たとえば、ヒープ サイズが大きいときにシングル スペース ガベージ コレクタを使用している場合) によく起こり、そのため JRockit のデフォルトのガベージ コレクション方式は -Xgcprio:throughput となっています。
回避策 : 最善の方法は、ファイナライザに頼らず、不要になった時点でネイティブ リソースを必ず解放することです。オブジェクトが到達不能になってしばらく経過しないとファイナライザは実行されないことに注意してください。proc というプロセスを閉じるには、次のような操作を行います。
proc.waitFor(); // プロセスの終了を待つ - 子プロセスがすでに終了していれば即復帰する
proc.getInputStream.close(); // 各ストリームを順に閉じる - 内部的な順序は重要でない
proc.getOutputStream.close();
proc.getErrorStream.close();
必要なら別スレッドでこれを非同期に行うこともできます。これはネイティブ ファイル ハンドルを使う通常のストリーム オブジェクト (たとえば、FileInputStream) のほか Socket のようなオブジェクトにも当てはまります。
これより効率は落ちますが、ガベージ コレクションを世代別で実行したりオブジェクト ヒープ サイズが小さくなるようにガベージ コレクション方式を調節する方法もあります。この場合、アプリケーションに伴ってネイティブ リソースが解放されるかどうかは運次第となります。
タイム ゾーンの更新
夏時間の変更に対応するために、タイム ゾーン情報を更新する必要があります。どうすればよいでしょうか?
タイム ゾーン 情報の詳細については、「Oracle JRockit Time Zone Updater」を参照してください。
Oracle JRockit Time Zone Updater は Sun TZUpdater と同じですか?
厳密には異なりますが、非常に似ています。
Sun TZUpdater では、タイム ゾーン データ キャッシュをクリアすると、Windows 上の特定のバージョンの JRockit がクラッシュします。これにより、Oracle のバージョンでは、これのキャッシュがクリアされません。この結果、Oracle バージョンのツールでは、キャッシュに古いタイム ゾーンが含まれる可能性があるので、アップグレードのすぐ後、JRE アップグレードの検証テストを行うことはできません。回避策は、JRE をアップグレードした後で、-t フラグを指定して TZUpdater を実行し、タイム ゾーン データが更新されていることを検証することです。
ツールの使用方法については、「Oracle JRockit Time Zone Updater」を参照してください。
Java 1.4.2_12 には、EST (東部標準時) に DST (夏時間) が適用されないというバグがあります。TZUpdater でこのバグは修正されますか?
いいえ、デフォルトでは対応していません。EST の問題はバグとは見なされていません。3 文字のタイム ゾーン ID の使用は Java 1.4 から非推奨になりました。(Olsen タイム ゾーン データベースの) tzdata2005r から、DST は EST に適用されていません。Sun は、Java 1.1.x との互換性よりも、Olsen tzdata (および Solaris と Linux) との互換性の方を選択しています。推奨される解決策は、「EST」の代わりに Olsen タイム ゾーン ID の「America/New_York」を使用することです。ただし、-bc 引数を指定して tzupdater を実行すると、EST に関する従来の下位互換性のある方法を使用できます (もちろん、新しい夏時間ルールも含まれています)。
この問題は、JRockit JVM の次のバージョンで修正されています。
- R27.3.1 142_14
- R27.4.0 150_12
- R27.3.1 1.6.0_01
使用中の TZUpdater のバージョンを確認するにはどうすればよいでしょうか?
使用中の TZUpdater のバージョンを確認するには、コマンド tzinfo を使用します。Oracle JRockit バージョン ディレクトリの bin/ directory からコマンドを入力します。詳細なバージョン情報が表示されます。次に例を示します。
以下に示すように入力します。
\jrockits\R27.3.0_R27.3.0-45_1.5.0\bin\tzinfo
システムは以下のように応答します。
java version "1.5.0_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
Oracle JRockit(R) (build R27.3.0-45-79733-1.5.0_10-20070330-1521-windows-ia32,
compiled mode)
タイム ゾーン データ バージョン : tzdata2006k
その他の情報
Oracle JRockit に関して話し合えるフォーラムはどこにありますか?
管理者向けのニュースグループについては次のリンクを参照してください。http://forums.bea.com/bea/forum.jspa?forumID=2009.
JRockit JVM に関する問題を Oracle サポートに送信するにはどのようにしたらよいですか?
問題に関するレポートを送信するには、「Oracle サポートへのトラブル レポートの送付」を参照してください。
|
