| Oracle® Enterprise Manager Cloud Control Oracle Fusion Middlewareマネージメント・ガイド リリース12.1.0.8 B66835-11 |
|
 前 |
 次 |
| Oracle® Enterprise Manager Cloud Control Oracle Fusion Middlewareマネージメント・ガイド リリース12.1.0.8 B66835-11 |
|
前 |
次 |
この章では、JVM診断のデプロイおよび使用時に発生する可能性のあるエラーと、そのエラーを解決するための手順について説明します。この章には次の項目があります。
この項では、JVM診断エンジンのステータスを表示するエラーの一覧を表示します。階層間の機能エラーは、次のような原因で発生する可能性があります。
一致しないデータベース接続情報
ユーザー権限不足
データベース・エージェント・エラー
「パフォーマンス診断」ページで、「上位SQL」グラフまたは「上位DBWaitイベント」グラフに「不明」エントリがあり、「上位データベース」グラフに未定義エントリがあり、かつ、「ライブ・スレッド分析」ページの「DB待機」リンクをクリックしたときに「データベース詳細」ポップアップ・ウィンドウが表示された場合は、多層間の相互関係を確立できません。
|
注意: 多層間の相互関係が確立されている場合は、「ライブ・スレッド分析」ページの「DB待機」リンクをクリックすると、データベース・インスタンスのデータベース診断ページが表示されます。その場合、「JVMパフォーマンス診断」ページの「上位SQL」と「上位DBWaitイベント」、および「上位データベース」の各グラフにはそれぞれ「不明」および「未定義」エントリは含まれません。カスタム・データベースの場合、「DB待機」リンクは無効になっています。 |
解決方法
データベースの不一致のために多層間の相互関係を確立できない場合は、データベースが登録されているかどうか調べてください。「設定」メニューから、「ミドルウェア管理」、「アプリケーション・パフォーマンス管理」の順に選択します。「JVM診断エンジン」を選択して、「構成」をクリックします。「データベースの登録」タブをクリックして、データベースが登録されているかどうかを調べます。データベースが登録されていなかった場合は、「DB待機」リンクをクリックしてJDBC接続文字列を検査し、JVM診断に登録されているデータベースにそれが一致しているかどうか、確認します。たとえば、JDBC接続文字列にSIDが含まれている場合は、登録されているデータベースはSIDを持っている必要があります。同様に、JDBC接続文字列にあるサービス名とデータベースのホスト名も、登録されたデータベースのものと一致する必要があります。一致することが必要なそうした情報の別の例として、データベースのホスト名があります。
カスタム・データベースの場合は、ユーザーの権限が不足している場合があります。その場合は、v$active_services、v$instance、v$session、v$sqltext、v$processおよびv$session_wait表に対する権限がユーザーにあるかどうかを調べます。
「設定」メニューから、ミドルウェア管理、「アプリケーション・パフォーマンス管理」の順に選択します。「JVM診断エンジン」を選択して、「構成」をクリックします。「データベースの登録」タブをクリックして、登録されているデータベースにJVM診断のDBエージェントが必要かどうかを調べます。必要な場合は、正しいIPアドレスおよびポート番号でデータベースがインストールされているマシンで、データベース・エージェントが稼働していることを確認します。
JVM診断エージェントから返されたJDBCのURLが、登録されたデータベースのうちのいずれかであるが、データベースの不一致やホスト名の誤りなどのために多層間の相互関係を確立できない場合は、そのJDBC URLを登録済データベースと関連付ける必要があります。次のページから、JDBC URLをデータベースと関連付けることができます。
「ライブ・スレッド分析」ページ: 「Java仮想マシン」メニューから、「ライブ・スレッド分析」を選択します。「JVMスレッド」表で、DB待機状態のスレッドを選択し、「DB URLの管理」をクリックします。「登録されたデータベースの関連付け/関連付け解除」で、JDBC URLを選択して「追加」をクリックし、関連付ける登録済データベースのURLを指定します。
「JVMパフォーマンス診断」ページ: 「Java仮想マシン」メニューから「パフォーマンス診断」を選択します。「JVMスレッド」表で、DB待機状態のスレッドを選択し、「DB URLの管理」をクリックします。「登録されたデータベースの関連付け/関連付け解除」で、JDBC URLを選択して「追加」をクリックし、関連付ける登録済データベースのURLを指定します。
「登録済データベース」ページ: 「設定」メニューから「ミドルウェア管理」、「アプリケーション・パフォーマンス管理」の順に選択します。「アプリケーション・パフォーマンス管理エンジン」表で「JVM診断エンジン」行を選択して、「構成」をクリックします。
「データベースの登録」タブをクリックします。「JVM診断登録済データベース」ページが表示されます。登録済データベースのリストが表示されます。データベースを選択し、「DB URLの管理」をクリックします。登録済データベースの関連付け/関連付け解除で、データベースURLを選択して「追加」をクリックし、関連付けるデータベースのURLを指定します。
JVM診断エージェントのホスト名と、データベースのV$ESSION表に保管されているマシン名が不一致(マシンの論理名の付け方が一貫していないなど)のために多層間の相互関係が確立できない場合は、次の手順を実行します。
Enterprise Managerのjam_jvm表にあるv$SESS_MACHINE列を、データベースのV$SESSIONで指定された正しい値で更新します(例: update jam_jvm set V$SESS_MACHINE = 'JVMD Agent Machine name' where jam_jvm_id ='jam_jvm_id')
データベースがJVM Diagnostics Managerにアクセスできないために多層間の相互関係が確立できない場合は、ログ・ファイルでデータベース名を調べ、そのデータベースが停止または非アクティブではないか、あるいはリスナーが停止していないか、確認します。そうである場合、JVM Diagnostics Managerはデータベースに接続して多層間の相互関係を確立することができません。
前述のすべての手順を実行しても、多層間の相互関係がまだ確立できない場合は、JVMDマネージャのログ・ファイルをパージする必要があります(*.out)。「設定」メニューから、「ミドルウェア診断」、「アプリケーション・パフォーマンス管理」の順に選択します。「JVM診断エンジン」を選択し、「構成」をクリックして、「JVMDエンジン・ログ・レベル」と「クロス層ログ・レベル」を一時的に「トレース」に設定します。
監視を一時的にオフにして(可能な場合)、アプリケーションがDB呼出しを行うとき(「DB待機」に1つ以上のスレッドがある必要があります)に「ライブ・スレッド分析」に移動し、JVMDマネージャのログを送信して問題のレポートを作成します。元のログ・レベルに戻し、監視を再度オンにします。
この項ではトレース中に発生するエラーの一覧を表示します。「ポーリング継続時間」の値が大きいためタイムアウトが生じた場合は、次のエラーが発生します。
エラー: weblogic.transaction.internal.TimedOutException: トランザクションは30秒後にタイムアウトしました。
解決策: このエラーはトレースの機能に影響しないため、無視できます。
この項では、デプロイメント・スクリプトの実行時に発生するエラーの一覧を表示します。
エラー: スクリプト例外: デプロイの実行中にエラーが発生しました: 実行したアクションは600,000ミリ秒後にタイムアウトしました。
解決策: この問題を解決するには、ターゲットのWebLogicドメイン管理コンソールのロックがすでに取得されているかどうか確認します。取得済の場合はそれを解放して、次の手順に従ってスクリプトを再度実行します。
WebLogic管理コンソール、http://<machine address>:<webogic port>/consoleにログインします。
保留中の変更が存在しないかどうかを確認します。保留中の変更が存在する場合、状況に応じて、それらの変更をアクティブ化するかまたは取り消して、スクリプトを再実行します。
エラー: WebLogic管理サーバーのユーザー名とパスワードが誤っている場合は、次のエラーが表示されます。
Caused by: java.lang.SecurityException: User: <username>, failed to be authenticated.
このメッセージは一般に長いエラー・メッセージの末尾にあります。
次の例外が表示されることもあります。
javax.naming.AuthenticationException [Root exception is java.lang.SecurityException: User: weblogic, failed to be authenticated.] at weblogic.jndi.internal.ExceptionTranslator.toNamingException(ExceptionTranslat or.java:42) at weblogic.jndi.WLInitialContextFactoryDelegate.toNamingException(WLInitialContextFactoryDelegate.java:788) at weblogic.jndi.WLInitialContextFactoryDelegate.pushSubject(WLInitialContextFact oryDelegate.java:682) atweblogic.jndi.WLInitialContextFactoryDelegate.newContext(WLInitialContextFactoryDelegate.java:469) at weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialConte xtFactoryDelegate.java:376) at weblogic.jndi.Environment.getContext(Environment.java:315) at weblogic.jndi.Environment.getContext(Environment.java:285) at weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFactor y.java:117) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:235) at javax.naming.InitialContext.initializeDefaultInitCtx(InitialContext.java:318) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:348) at javax.naming.InitialContext.internalInit(InitialContext.java:286) at javax.naming.InitialContext.<init>(InitialContext.java:211)
解決策: WebLogic管理サーバーの正しいユーザー名とパスワードを入力して、スクリプトを再度実行します。
エラー: この例外は、weblogic.jarへのパスが無効であるか、またはユーザーにweblogic.jarファイルの読取り権限がない場合に発生することがあります。
Exception in thread "main" java.lang.NoClassDefFoundError: javax/enterprise/deploy/spi/exceptions/TargetException Caused by: java.lang.ClassNotFoundException: javax.enterprise.deploy.spi.exceptions.TargetException at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:252) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
解決策: 正しいパスを指定するか、ユーザーにjarファイルへの読取り権限のある資格証明を付与します。
エラー: WebLogic管理コンソールがロックされていると、エージェントのデプロイメント・ジョブは予期したように動作しないことがあります。WebLogicドメインがロックされているためagent.logファイルがデプロイできない、というメッセージが表示されます。
解決策: JVM診断エージェントはt3/t3sプロトコルを使用してデプロイされます。t3/t3sポートが開いていることを確認します。
エラー: SSLを有効にしたWebLogicドメインに、デモ用証明書を使用してデプロイするとき、WebLogicサーバーのデモ用証明書がキーストアにインポートされていない場合にエラーが表示されることがあります。
解決策: WebLogic Serverターゲットを監視している管理エージェントのキーストアに、WebLogic Serverのデモ資格証明をインポートします。
エラー: deployer.zipまたはjavadiagnosticagent.earファイルのコピー中にBroken pipeエラー(接続が失われた)のようなエラーが表示されます。
解決策: Oracle Management Serviceおよび管理エージェントは、同じグループに属する同じユーザーによりインストールされる必要があります。
エラー: JVMD AGENT DEPLOYMENT FAILED FOR WEBLOGIC 9.2 TARGET.
次の例外が発生します。
EM Agent home : /scratch/aime/agsh_0819/core/12.1.0.2.0 MIDDLEWARE_HOME : /scratch/aime/mw923 IS_WEBLOGIC9 : true em agent state dir : /scratch/aime/agsh_0819/agent_inst acsera home : /tmp/ad4j_1345730608009/4910760210525348050 wls admin url : t3://emHost.example.com:7001 wls username : weblogic target : AdminServer? weblogic jar path : /scratch/aime/mw923/weblogic92/server/lib/weblogic.jar&&ls /scratch/aime/mw923/weblogic92/server/lib/wljmxclient.jar&&ls /scratch/aime/mw923/weblogic92/server/lib/wlcipher.jar application name : HttpDeployer? agent keystore location : /scratch/aime/agsh_0819/agent_inst/sysman/config/montrust/AgentTrust.jks Command used for deployment: /scratch/aime/agsh_0819/core/12.1.0.2.0/jdk/bin/java -cp /tmp/ad4j_1345730608009/4910760210525348050/ADPAgent/lib/mips.jar:/scratch/aim e/mw923/weblogic92/server/lib/weblogic.jar&&ls /scratch/aime/mw923/weblogic92/server/lib/wljmxclient.jar&&ls /scratch/aime/mw923/weblogic92/server/lib/wlcipher.jar -Dweblogic.security.SSL.ignoreHostnameVerify=true -Djava.security.egd=file:/dev/./urandom -Dweblogic.security.SSL.trustedCAKeyStore=/scratch/aime/agsh_0819/agent_inst/ sysman/config/montrust/AgentTrust.jks-Dsun.lang.ClassLoader.allowArraySyntax= true -Dbea.home=/scratch/aime/mw923 com.acsera.ejb.Deployer.RemoteHttpDeployerShell -deploy -adminurl t3://emHost.example.com:7001 -upload -source /tmp/ad4j_1345730608009/4910760210525348050/ADPAgent/deploy/HttpDeployer.ear -targets AdminServer? -username weblogic -name HttpDeployer? -usenonexclusivelock
まず、アプリケーションはターゲット・サーバーでアンデプロイされます
使用法: java [-options] class [args...]
(クラスを実行する場合)
またはjava [-options] -jar jarfile
(jarファイルを実行する場合)
次のオプションがあります。
d32 use a 32-bit data model if available
-d64 use a 64-bit data model if available -client to select the "client" VM -server to select the "server" VM -hotspot is a synonym for the "client" VM [deprecated] The default VM is server, because you are running on a server-class machine. -cp <class search path of directories and zip/jar files> -classpath <class search path of directories and zip/jar files> A : separated list of directories, JAR archives, and ZIP archives to search for class files. -D<name>=<value> set a system property -verbose[:class|gc|jni] enable verbose output -version print product version and exit -version:<value> require the specified version to run -showversion print product version and continue -jre-restrict-search | -jre-no-restrict-search include/exclude user private JREs in the version search -? -help print this help message -X print help on non-standard options -ea[:<packagename>...|:<classname>] -enableassertions[:<packagename>...|:<classname>] enable assertions -da[:<packagename>...|:<classname>] -disableassertions[:<packagename>...|:<classname>] disable assertions -esa | -enablesystemassertions enable system assertions -dsa | -disablesystemassertions disable system assertions -agentlib:<libname>[=<options>] load native agent library <libname>, e.g. -agentlib:hprof see also, -agentlib:jdwp=help and -agentlib:hprof=help -agentpath:<pathname>[=<options>] load native agent library by full pathname -javaagent:<jarpath>[=<options>] load Java programming language agent, see java.lang.instrument -splash:<imagepath> show splash screen with specified image /scratch/aime/mw923/weblogic92/server/lib/wljmxclient.jar ls: invalid line width: eblogic.security.SSL.ignoreHostnameVerify=true Status returned from the java process is 512
この項ではloadheapエラーの一覧を表示します。
エラー: ヒープダンプ操作中に次のエラーが発生します。
glibc detected * free(): invalid next size (fast): 0x0965d090" ./loadheap.sh:
line 237: 32357 Aborted ./bin/${bindir}/processlog in=$infile hdr=${sumdata}
obj=${objdata} rel=${reldata} root=${rootdata} osum=${objsumdata}
rrel=${rootrel} heap=${heap_id} skip=$skipgarbage db=$dbtype $* Error
processing file /tmp/heapdump6.txt
解決策: ヒープダンプ操作が正常に完了しているかどうか確認します。heapdump6.txtファイルを開いて、ファイルの最後にheapdump finishedの文字列があるかどうか確認します。この文字列がある場合は、終了したダンプ・ファイルをロードします。
エラー: ヒープダンプはすでに進行中で、別のヒープダンプは実行できません。
解決策: ヒープダンプ操作が正常に完了しているかどうか確認します。heapdump6.txtファイルを開いて、ファイルの最後にheapdump finishedの文字列があるかどうか確認します。
エラー: loadheap.shにより、使用できない一意の索引が作成されました。
解決策: loadheap.zipに付属しているloadheap/sql/cleanup.sqlを実行して、一意の索引を修正します。
IBM JDK 1.6でJVM診断エージェントをデプロイしようとすると、次のエラーが発生します。
エラー: JVM診断エージェントがJDK 1.6にデプロイされると、次のメッセージが表示される場合があります。
Jam Agent : can_tag_objects capability is not set. Copy /tmp/libjamcapability.so to another directory and restart Java with argument -agentpath: <Absolute path of libjamcapability.so>
解決策: 最新のjamagent.warをデプロイし、-agentpath:<Absolute path of libjamcapability.so after copying to another directory>をjava引数に追加します。
このメッセージはJVM診断エージェントがJVM診断エンジンに接続してからのみ、表示されます。2番目に、この引数はJVM引数である必要があります(プログラム引数ではありません)
WebLogic管理コンソールを使用して(ノードマネージャを介して)サーバーが起動される場合、これらの引数は管理コンソールの「サーバーの起動」の下で指定できます。サーバーがコマンドラインから起動される場合(startWeblogic.shまたはstartManagedServer.sh)、これらの引数はstartWeblogic.shで指定する必要があります。サーバーが複数台ある場合は、サーバー名の確認がstartWeblogic.shにあり、libjamcapability.soのパスがサーバーごとに異なっていることを確認してください。
startWeblogic.shでの入力例を次に示します。
if [ "${SERVER_NAME}" = "AdminServer" ] ; then
echo "********************************************* MODIFIED ADMIN SERVER"
JAVA_OPTIONS="${JAVA_OPTIONS} -agentpath:<Absolute path of
libjamcapability.so.X after copying to another directory>
export JAVA_OPTIONS
fi
サーバー起動時(jamagentログが表示される前)のメッセージ「Capabilities Added by libjamcapability.so」は、libjamcapability.soが正常にロードされたことを確認しています。
この項ではユーザー・インタフェース・エラーの一覧を表示します。
エラー: これはエージェントのタイムアウト・エラーです。
JAM Console:Socket timed out after recv -- client emHost.example.com:7001 is not Active [0] secs JAM Console jamlooptimeout=[3] JAM CONSOLE: JVM 1 is not active JAM Cons ErrProcessing Request:128 JVM 1 is not active jamDAL: jamreq returned 128 return status < 0 from jamDalInst.processRequest
解決策: このエラーを解決するには、「エージェント・リクエスト・タイムアウト」および「エージェント・ループ・リクエスト・タイムアウト」の値を増やします。
エラー: JVM診断エージェントは起動され、稼働しているが、リアルタイム・ページに表示されません。
解決策: ログ・ファイルにJAMMANAGER: OLD AGENTまたはNULL POOLと表示されていたり、最適化レベルが誤っている場合、これは、古いJVM診断エージェントまたはDBエージェントが使用されていることを示しています。この問題を解決するには、次の手順を実行します。
「設定」メニューから、「アプリケーション・パフォーマンス管理」を選択します。
「アプリケーション・パフォーマンス管理エンジン」のリストが表示されます。
「JVM診断エンジン」行をクリックし、「構成」、「データベースの登録」タブの順にクリックします。
「登録されているDBエージェント」リージョンの「ダウンロード」ボタンをクリックして、JVMDコンポーネント・リストから「JVMDエージェント」を選択します。JVM診断エージェントWeb xmlパラメータを指定し、「ダウンロード」、「OK」の順にクリックして、jamagent.warファイルをダウンロードします。
エラー: このページを表示するために必要な権限がありません。
解決策: JVM診断データを表示するために必要なJVM診断管理者権限またはユーザー権限があることを確認してください。
この項では、JVM診断エンジンをデプロイしたときに発生する可能性のあるエラーをリストします。
エラー: JVMD管理対象サーバーの起動に失敗して、JVMDデプロイメントが失敗しました。
<domain_JVMDMANAGER>という名前のサーバーの起動に失敗しました。失敗した手順は次に示すとおり、ノード・マネージャへの接続が接続拒否により失敗したことを示すログを残しています。NodeManagerに接続できませんでした
解決策: この問題を解決するには、次の手順に従います。
JVM診断エンジンがデプロイされているOMSサーバーに、起動したマシンが関連付けられていることを確認します。
WebLogic管理コンソールを使用してデプロイしたばかりのJVM診断エンジンを起動します。
Enterprise ManagerコンソールからWebLogicドメインをリフレッシュします。
この項では、JVM診断の使用中に生じる可能性のある質問の一覧を表示します。次が含まれています。
JVM診断ログは次の場所にあります。
JVM診断エンジンのログ・ファイルは、$EMGC_JVMDMANAGER1/logs/EMGC_JVMDMANAGER1.outにあります。
UI関連エラーのログの場所は次のとおりです。
$T_WORK/gc_inst/user_projects/domains/GCDomain/servers/EMGC_OMS1/logs/EMGC_OMS1.out
$T_WORK/gc_inst/user_projects/domains/GCDomain/servers/EMGC_OMS1/logs/EMGC_OMS1.log
JVM診断エンジンとコンソール間の通信エラーのログ・ファイルは、$T_WORK/gc_inst/em/EMGC_OMS1/sysman/log/emoms.logにあります。
JVM診断エンジンのステータスを確認するには、次の手順を実行します。
「設定」メニューから「ミドルウェア診断」を選択し、「JVM診断の設定」をクリックします。
JVM診断エージェントのログ・ファイルを確認して、エージェントとマネージャ間の通信を検証します。JAM Agent ERROR: Cannot connect to Console:Connection refusedというエラーが表示されている場合、これはJVM診断エンジンが稼働していないことを示しています。
JAM Console: Agent connection from:[Hostname]というメッセージが、JVM診断エンジンのログ・ファイル内にあるかどうか確認します。このメッセージが表示されている場合、これはJVM診断エンジンが稼働中でエージェントに接続されていることを示しています。
JVM診断エージェントのステータスを確認する手順:
「ターゲット」メニューから「ミドルウェア」を選択し、Java仮想マシン・ターゲットをクリックします。「Java仮想マシン」メニューから「ライブ・スレッド分析」オプションを選択します。「接続されているJVM」表でJVMのステータスを確認します。
ステータスが「非アクティブ」の場合、これはエージェントがマネージャに接続されていないことを示しています。エージェント・ログを確認して、エージェントが稼働中でマネージャのIPアドレスおよびポート番号が正しいかどうか検証します。
ステータスが「JVMDエージェントがデプロイされていません」の場合、JVM DiagnosticsエージェントをそのJVMにデプロイする必要があります。
JVM Diagnosticsエージェントが稼働している場合、アクティブ・スレッド・データが表示されます。JVM Diagnosticsエージェントが稼働していない場合、JVM is inactive, Please try again after some timeというメッセージが表示されます。
JVM診断エンジンがデータを監視中かどうか検証するには、次の手順を実行します。
「設定」メニューから「ミドルウェア診断」を選択し、「ミドルウェア診断」ページで「JVM診断の設定」をクリックします。「JVMD構成」ページで、「監視有効化」チェック・ボックスが選択されていることを確認します。
「設定」の下の「監視」ページに移動し、監視対象のJVMが属すプールに対する監視ステータスが「オン」かどうか確認します。
「設定」の下の「JVMプール」ページに移動し、監視対象のJVMが属すプールに対して「ポーリング有効」チェック・ボックスが選択されているかどうか確認します。以上で、監視が有効になります。
loadHeapスクリプトを使用してヒープのみをロードできる権限の低いユーザーを作成する場合、create_jvm_diagnostic_db_user.shスクリプトを実行できます。
JVM診断エージェントは3つの最適化レベルをサポートしています。
レベル0は、JVM診断エージェントがJVMTIベース・エンジンを使用していることを示します。このレベルは、サポートされているほとんどすべてのプラットフォームでJDK 6シリーズに対してサポートされています。
レベル1はレベル0とレベル2の混合です。選択したプラットフォーム上のごくわずかなJDKに対してのみサポートされています。
レベル2は実行時が効率的なので、ランタイム・オブジェクト分析手法を使用して監視します。
カスタム・プロビジョニング・スクリプトを実行すれば、本番環境でのJVMDエージェントのデプロイメントをカスタマイズできます。
OMSがインストールされていれば、ミドルウェアのインストール・ディレクトリのplugins/oracle.sysman.emas.oms.plugin_12.1.0.0.0ディレクトリにjvmd.zipファイルが見つかります。zipファイルのcustomprovディレクトリに、一連のスクリプトが含まれています。これらのスクリプトの使用方法は、同じディレクトリにあるREADME.TXTに詳しく説明されています。カスタム・プロビジョニング・スクリプトを使用するには、次の手順を実行します。
「設定」メニューから「ミドルウェア診断」を選択し、「ミドルウェア診断」ページで「JVM診断の設定」をクリックします。「データベースの登録」タブをクリックして、jamagent.warファイルをダウンロードします。
ダウンロードしたjamagent.warの場所、ドメインおよびサーバーの詳細が記載されたデプロイメント・プロファイルのコピーを作成します。
デプロイメント・プロファイル上でPerl scriptを実行すると、指定したすべてのサーバーにJVMDエージェントがデプロイされます。
デフォルトのログ・マネージャ・レベルは3です。なんらかの問題が発生した場合は、このレベルを一時的に上げることができます。次の1から5のログ・レベルがサポートされています。
1 - エラー
2 - 警告
3 - 情報
4 - デバッグ
5 - トレース
監視データには、JVMごとに1日当たり50MB、パージ間隔はデフォルトで24時間に設定することをお薦めします。この容量は、使用する環境の実行時要因(コール・スタックの深さなど)によって変わる可能性があります。そのため、表領域の増加を定期的にチェックし、必要に応じて領域要件を変更する必要があります。こうすれば、急激なスパイクが発生することなく、通常の監視によるデータベースの増加にスムーズに対応することができます。表領域のサイズ変更は、次の要因によって影響を受ける場合があります。
ヒープ・ダンプ: ヒープの分析には大量の表領域が必要です。標準的な対処方法として、ロードされるヒープ・ダンプ・ファイルのサイズの5倍の空き領域を表領域に確保しておくことをお薦めします。ダンプ・ファイルのサイズはわかるため、データベースにロードされる前に、ダンプ・ファイルを収容するのに十分な領域があることを確認します。
スレッド・トレース: これらはヒープより小さくなっています。ユーザーがコンソールでトレースを開始すると、これらがデータベースに自動的にロードされます。これらのスレッドのサイズは、トレース時のアクティブ・スレッドの数、トレースの期間およびトレースのサンプル間隔に応じて大きく異なります。通常は100MB未満ですが、複数のスレッド・トレースが開始されていると、データベースがすぐに一杯になる可能性があります。トレースを開始する前に、データベースに十分な領域があることを必ず確認してください。
