Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Sv translation
languageja

アプリケーションサーバーのJavaプロセスを監視する

BellaDatiはアプリケーションサーバー上で実行されるJavaアプリケーションであり、VisualVMなどのJVMツールを使用して、BellaDatiのメモリやスレッドなどの使用状況を監視でき、パフォーマンスの問題を解決するための貴重な情報を得ることができます。

VisualVMがBellaDatiをホストする実行中のアプリケーションサーバーのJavaプロセスに接続する方法は2つあります:

  • 直接 - VisualVMをアプリケーションサーバーと同じマシンで実行できる場合 または
  • JMX - VisualVMを同じサーバーで実行できない場合 (例:アプリケーションサーバーは、UIがないマシンで実行されているか、アクセスできない管理対象サーバーで実行されている)

JMXを有効にする

アプリケーションサーバーを実行しているJavaプロセスへのJMX接続を有効にするには、次のJVMオプションを追加する必要があります:

Code Block
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.local.only=true
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.rmi.port=9010
-Dcom.sun.management.jmxremote.port=9010
-Djava.rmi.server.hostname=localhost		

Once JVM options are added and application server is restarted, VisualVM can be connected to it by creating JMX connection to JVMオプションが追加され、アプリケーションサーバーが再起動されると、<server-address>:9010. In case the port is not publicly available and SSH connection is possible, port can be made available by port forwarding, e.g. on Linux based systems via::9010 へのJMX接続を作成することにより、VisualVMをそれに接続できます。ポートが公開されておらず、SSH接続が可能な場合は、ポートフォワーディングによってポートを使用可能にすることができます: 例: Linuxベースのシステム

ssh -L 9010:localhost:9010 <user>@<host>

GCログを収集する

In case of memory issues, Java process running application server can be configured to collect garbage collection (GC) logs as well as to generate a heap dump in case of OutOfMemoryError. Also, switching the type of garbage collection algorithm can improve performance. To enable GC logs generation and heap dump generation as well as switch GC algorithm to G1 add following JVM options in the application serverメモリの問題が発生した場合、アプリケーションサーバーを実行しているJavaプロセスは、ガベージコレクション (GC) ログを収集し、OutOfMemoryErrorの場合にヒープダンプを生成するように構成できます。また、ガベージコレクションアルゴリズムのタイプを切り替えると、パフォーマンスを向上させることができます。 GCログの生成とヒープダンプの生成を有効にし、GCアルゴリズムをG1に切り替えるには、アプリケーションサーバーに次のJVMオプションを追加します:

Code Block
-XX:+UseG1GC
-Xloggc:<gc-log-dir>/gc-%t.log
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=20
-XX:GCLogFileSize=50M
-XX:+SafepointTimeout
-XX:+UnlockDiagnosticVMOptions
-XX:SafepointTimeoutDelay=1000
-XX:+PrintSafepointStatistics
-XX:PrintSafepointStatisticsCount=1
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=<heap-dump-dir>

where

  • <gc-log-dir> is the absolute path to the directory in which GC logs should be stored anddir> GCログを保存するディレクトリへの絶対パスです。
  • <heap-dump-dir> is the absolute path to the directory in which the generated heap dump should be stored.dir> 生成されたヒープダンプを保存するディレクトリへの絶対パスです。
Info
titleGC logs files rotation

The above configuration enables the GC log file rotation after the file reaches 50MB. Up-to 20 files are kept before the old ones are removed.上記の構成により、ファイルが50MBに達した後のGCログファイルのローテーションが有効になります。古いファイルが削除される前に、最大20個のファイルが保持されます。


Warning
titleGC log file name

The above configuration generates a new GC log file name every time application server is started. The %t part in the file name converts to the current date & time of the server. The generated file name is kept for the whole run of the application server, even after log file rotation. Once the application server is restarted a new file name is generated and old ones are not deleted, old files must be deleted manually. Alternative is to exclude the %t part, but then existing GC log(s) needs to be copied before application server is restarted otherwise they will be overwritten.上記の構成では、アプリケーションサーバーが起動するたびに新しいGCログファイル名が生成されます。ファイル名の %t 部分は、サーバーの現在の日時に変換されます。生成されたファイル名は、ログファイルのローテーション後も、アプリケーションサーバーの実行全体にわたって保持されます。アプリケーションサーバーを再起動すると、新しいファイル名が生成され、古いファイルは削除されないため、古いファイルを手動で削除する必要があります。別の方法は、%t部分を除外することですが、アプリケーションサーバーを再起動する前に、既存のGCログをコピーする必要があります。そうしないと上書きされます。