Versions Compared

Old Version 4

changes.mady.by.user Kanako Higashi

Saved on

compared with

New Version Current

changes.mady.by.user Martin Trgiňa

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Removed translated content for 'zh'
Sv translation
languageen

Monitor application server's Java process

As BellaDati is a Java application run on the application server and JVM tools like VisualVM can be used for monitoring the BellaDati's usage of memory, threads, etc. and can be a source of valuable information in solving performance issues.

There are 2 ways how the VisualVM can connect to the Java process of the running application server which host BellaDati:

  • directly - when VisualVM can be run on the same machine as the application server or
  • JMX - when VisualVM can't be run on the same server, e.g. application server is run on machine which has no UI or is run on some managed server you have no access to.

Enable JMX

To enable JMX connection to the Java process running application server following JVM options need to be added to it:

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 <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:

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

Collect GC Logs

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:

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 and
  • <heap-dump-dir> is the absolute path to the directory in which the generated heap dump should be stored.
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.


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.


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

JVMオプションが追加され、アプリケーションサーバーが再起動されると、<server-address>:9010 へのJMX接続を作成することにより、VisualVMをそれに接続できます。ポートが公開されておらず、SSH接続が可能な場合は、ポートフォワーディングによってポートを使用可能にすることができます: 例: Linuxベースのシステム

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

GCログを収集する

メモリの問題が発生した場合、アプリケーションサーバーを実行している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> GCログを保存するディレクトリへの絶対パスです。
  • <heap-dump-dir> 生成されたヒープダンプを保存するディレクトリへの絶対パスです。
Info
titleGC logs files rotation

上記の構成により、ファイルが50MBに達した後のGCログファイルのローテーションが有効になります。古いファイルが削除される前に、最大20個のファイルが保持されます。


Warning
titleGC log file name

上記の構成では、アプリケーションサーバーが起動するたびに新しいGCログファイル名が生成されます。ファイル名の %t 部分は、サーバーの現在の日時に変換されます。生成されたファイル名は、ログファイルのローテーション後も、アプリケーションサーバーの実行全体にわたって保持されます。アプリケーションサーバーを再起動すると、新しいファイル名が生成され、古いファイルは削除されないため、古いファイルを手動で削除する必要があります。別の方法は、％t部分を除外することですが、アプリケーションサーバーを再起動する前に、既存のGCログをコピーする必要があります。そうしないと上書きされます。