概要

パフォーマンスの問題のトラブルシューティングは簡単なプロセスではなく、Jira アプリケーションの問題を特定する際には非常に複雑になる場合があります。さまざまなバージョン、プラグイン、ネットワーク、ハードウェア構成、その他のさまざまな要素などの、Jira アプリケーションで考えられる構成の数を考慮すると、このような問題の解決はさらに困難になります。このナレッジベース記事は、この作業を簡単に行えるようにし、問題を特定したりサポートに情報を提供したりするためのガイダンスを提供することを目的としています。

パフォーマンスの問題のトラブルシューティングでは多くの場合、1 つ以上の症状について原因を 1 つずつ切り分け、それが根本原因であるかどうかを検証することになります。これをディスカバリ (インスタンスの診断情報の収集) で行い、次にその情報を分析して問題を特定できるかどうかを確認します。この作業では多くの場合、何か小規模の変更を行い、その変更がインスタンスの安定性に影響するかどうかをテストします。これはインスタンスの複雑性 (プラグイン、ハードウェア構成など) の複雑性によっては時間がかかる可能性があります。

よく使われる用語

Jira アプリケーションのハードウェア構成

Jira のソフトウェア構成

症状

ブラウザで、Jira アプリケーションの応答や読み込みが全体的に遅い。

• ネットワークの接続性
• アプリケーション
• リバース プロキシ/ロード バランサ
• ハードウェア リソース
• ブラウザのパフォーマンスの問題
• インスタンスまたはサーバーのキャパシティ上限/利用超過
• ディスク速度
• データベース
• アプリケーションのバグ (Jira、JVM、カーネル/OS)
• プラグイン (サードパーティまたはバンドル)

Jira アプリケーションが応答を返さない。

• ネットワークの接続性
• アプリケーション
• リバース プロキシ/ロード バランサ
• ハードウェア リソース
• ブラウザのパフォーマンスの問題
• インスタンスまたはサーバーのキャパシティ上限/利用超過
• ディスク速度
• データベース
• アプリケーションのバグ (Jira、JVM、カーネル/OS)
• プラグイン (サードパーティまたはバンドル)

CPU 利用率が極端に増える (80-100 % の利用率)

• ハードウェア リソース
• JVM 構成/不十分なメモリ
• インスタンスまたはサーバーのキャパシティ上限/利用超過 
• アプリケーションのバグ (Jira、JVM、カーネル/OS) 
• プラグイン (サードパーティまたはバンドル)

OutOfMemoryError による Jira アプリケーションのクラッシュ

• OutofMemory Java ヒープ スペース エラーが発生して Jira Server / Data Center がクラッシュする
• GC overhead limit exceeded エラーによって Jira Server がクラッシュする
• JVM 構成/不十分なメモリ 
• アプリケーションのバグ (Jira、JVM、カーネル/OS) 
• プラグイン (サードパーティまたはバンドル)

基盤となるコネクション プールからコネクションを取得できない

• Jira サーバーで処理に失敗し、ログにコネクション プールのエラーが記録される
• データベース

In order to proceed through this step, please step-through each common problem one-by-one, determining whether it is the cause of the relevant symptom.

ネットワークの接続性

Verify with the Sys Admin / hosting provider if there are any problems with the network and/or server. You can also perform checks by pinging or using netcat or telnet to connect to the server on the port where JIRA applications are hosted, such as:

ping 192.168.1.123
telnet 192.168.1.123 8080
Or,
root@kali:~# nc -vnz -w 1 192.168.1.123 8080
Connection to 192.168.1.123 8080 port [tcp/*] succeeded!
root@kali:~#

Netcat and telnet can be used to verify if the Firewall is blocking that port, and tools like https://tools.keycdn.com/ping or https://ping.eu/ can be used to diagnose geographic-specific latency problems. For a comprehensive isolation test, connect to the server over the local network to verify if there are any network problems.

アプリケーション

1. アプリケーションが起動している (Tomcat プロセスが実行されている) かどうかを確認します。

2. Review the logs to see if there are any errors or exceptions and stack traces. Check https://jira.atlassian.com, the Jira and Jira Service Management Knowledge Base and Google for those Exceptions/errors.
3. Take 3 thread dumps, 10 seconds apart as per our Generating a Thread Dump docs to analyse. This will give a breakdown of exactly what the instance is doing when it's locked up.

スレッド ダンプを分析すると、アプリケーションのロックアップ要因を確認できる場合があります。スレッド ダンプは、アプリケーションの失敗または低速なパフォーマンスの最中に取得された場合にのみ有益です。Jira アプリケーション インスタンスが安定した状態で取得しても、問題ではなく Jira アプリケーションが安定している旨のみが記録されるため、役に立ちません。スレッド ダンプの分析方法の例については次のサイトをご確認ください。

• http://architects.dzone.com/articles/how-analyze-java-thread-dumps
• http://www.javacodegeeks.com/2012/03/jvm-how-to-analyze-thread-dump.html

また、次の内容をご確認ください。

• [管理] > [システム] > [トラブルシューティングとサポート] > [ロギングとプロファイリング] でプロファイリングを有効化してテストを行うと問題を特定できる場合があります。
• Also, profiling the instance with jProfiler, as per our Use jProfiler to analyse Jira application performance KB will give an exact breakdown of the classes and methods that are the slowest to respond.

リバース プロキシ/ロード バランサ

If using a reverse-proxy / load-balancer, try bypassing it and access the instance directly, e.g.: http://<IP_of_node>:8080/jira to see if there is any difference.

Analyzing the access logs with our Jira HTTP Requests Log Analyzer is an excellent way of diagnosing if the instance is being overloaded. If so, it can increase response times and those logs will also assist in identifying the culprits.

ハードウェア リソース

1. Verify the JIRA application Requirements are met and check the CPU load of the JIRA application instance to see if it is high, as if the CPU is consumed by another process (or by a JIRA application), it may be slow to respond.
2. 1 つのサーバーに複数のアプリケーションがある場合、すべてのアプリケーションに十分なリソースがあることを確認します。JVM に要求されるリソースを計算するには、permgen に最大ヒープ サイズを追加し、JVM 用に 128 MB を追加します。例:

アプリケーションがインストールされているサーバーの場合、これら 2 つのアプリケーションを提供するのに 3328 MB が要求されるほか、オペレーション システム用のオーバーヘッドを追加する必要があります。マシンでは最小でも 4 GB が利用可能である必要があり、マシンは 64 bit である必要があります。また、同じサーバー上のほかのアプリケーション (データベースなど) の要件も考慮するようにします。

There are known problems if the server hosting JIRA applications is running 32-bit and other JVM applications, as in our JIRA crashes when running as a Windows Service KB.

ブラウザのパフォーマンスの問題

Try using a different browser to see if there is any difference in the response - IE (especially IE8) will typically be significantly slower than Chrome to render content. For further assistance diagnosing problems, take a look through our Troubleshooting Client-Side Browser Problems KB.

ブラウザの問題の分離テストは、クロスブラウザでのテストを行うことです。ブラウザを横断して問題が継続している場合、サーバー側のパフォーマンスである可能性があります。

インスタンスまたはサーバーのキャパシティ上限/利用超過

• There is no hard and fast rule on this as it often depends on the database stats (issues, custom fields, workflows, users, security schemes and so on) and the JIRA application version. Providing a Support ZIP to Atlassian Support is enough for us to provide some rough recommendations on the instance. It may be that an upgrade is required if the instance is too large for the version.
• アクセス ログを収集して確認し、インスタンスで高負荷が発生しているかどうかを確認します。
• SOAP または REST を利用している外部アプリケーション連携がインスタンスを過負荷にしているかどうかを確認します。
• テスト サーバーを最新バージョンにアップグレードしてそこに本番環境を復元すると、パフォーマンスの問題がアップグレードで解決されるかどうかを特定できます。

Analyzing the access logs with our Jira HTTP Requests Log Analyzer is an excellent way of diagnosing if the instance is being overloaded. If so, it can increase response times and those logs will also assist in identifying the culprits.

ディスク速度

Poor disk I/O will cause poor performance with searches, gadgets, and issues with 10+ attachments.  Please see Troubleshooting Performance with Jira Stats on how to check your disk performance

アンチウイルス ソフトの「オンアクセス」は Jira アプリケーションとの相性が悪く、インデックス ディレクトリはオンアクセス スキャンから除外する必要があります。Symantec の特定のバージョンなどの一部の例ではこの例外が無視され、問題が継続します。このような場合はサーバーからアンチウイルス ソフトをアンインストールして別のソリューションを検討する必要がある場合があります。

Linux 環境の場合、noatime でファイルシステムをマウントするのを検討します。これは、ファイルの読み取り時にタイムスタンプを設定しないように OS に指示します。アプリケーションが Lucene インデックスやキャッシュ ファイルに、1 秒間に何千回もアクセスすると、atime の書き込みによってパフォーマンスが明確に悪化することがあります。ある事例によると、最大で 30 % の悪化が見られます。マウント オプションを変更する前に、atime に依存しているアプリケーションがほかにないことを確認する必要があります。同じようにメリットを提供する、より保存的な設定として、"relatime" があります。詳細については「Gain 30% Linux Disk Performance with noatime, nodiratime, and relatime」をご確認ください。

データベース

1. Verify the load on the database and the DB server - see also Please see Troubleshooting Performance with Jira Stats on how to check your DB performance. Additionally, this should be raised with the DBA for the server, as Atlassian Support are not experts on diagnosing and troubleshooting database problems.
2. Verify the validationQuery has been set as per Surviving Connection Closures and the database connection is configured as per the Connecting JIRA applications to a Database documentation.

JVM Configuration / Insufficient Memory

1. 最近 Jira アプリケーションのアップグレードを行いましたか? その場合、以前の JVM 構成が古いバージョンから移行されているかどうかを確認します。
2. If experiencing OOMEs, increase the maximum memory by small amounts (256mb) as per Increasing JIRA application memory to verify if the problem is still occurring.
3. Garbage Collection logs are required to analyze what's happening with the JVM memory that JIRA applications are using. These can be enabled as in our Troubleshoot Jira Server performance with GC logs KB article.
4. Set up the JVM so that it generates a heap dump automagically when an OOME is thrown, as per our Analyze OutofMemory errors in Jira Server and Data Center with heap dumps KB.
5. Check the logs for possible CodeCache warnings, addressed in more details in the Full CodeCache causes Jira to crash or perform slowly article.

Java の VisualVM をインストールして、Jira アプリケーションを実行しているプロセスをバインドするために使用できます。これを使用して、GC による CPU 使用状況やヒープの使用状況を分析できます。各ヒープ領域の視覚的な情報を提供する visualGC プラグインのインストールが推奨されます。

• GC ログの分析と、インスタンスの低速時との比較は、メモリの問題の切り分けに最適です。たとえば、インスタンスのパフォーマンスが特定のタイミングで遅い場合、そのタイミングで完全な GC が発生しているかどうかを確認します。これはアプリケーションの応答時間を低下させる可能性があります。
• CPU スパイクが発生している場合、完全な GC が一貫して行われているかどうかを確認します。ガベージ コレクションは CPU を消費します。JVM に提供されているメモリが不足している場合、より多くの GC サイクルが必要になるため、CPU の利用量が増えます。JVM に適切なメモリがあることを確認します。これが原因であるかどうかを切り分けるには、メモリを少量ずつ増やします。

アプリケーションのバグ (Jira、JVM、カーネル/OS)

Check https://jira.atlassian.com, the Jira and Jira Service Management Knowledge Base, Google and also the DB/OS/Java vendor to see if there are any bugs that present with performance symptoms. 

プラグイン (サードパーティまたはバンドル)

特にサードパーティまたはインハウス (内製) のプラグインは、Jira アプリケーションでさまざまな問題の原因になることがあります。DBCP やメモリ (ヒープ利用率) を消費したり、課題の処理を遅延させたり、他のさまざまな問題を発生させることがあります。ベスト プラクティスとして、プラクティスが 1 つも有効化されていない状態でパフォーマンスの問題が引き続き発生するかどうかを確認します。UPM でセーフ モードを有効化することで、プラグインが問題かどうかを確認できますが、インスタンスの機能が減らされるために影響が発生する可能性があります。これは業務に影響を与える可能性があるため、本番環境と同一の複製されたテスト インスタンスでこの操作を行うことをおすすめします。これは次のような分離テストでも行えます。

1. セーフ モードを有効化して問題が再現可能かどうかを確認します。再現されない場合、プラグインによって遅延が発生している可能性があります。問題が再現されなくなったら以降の手順を続けます。それ以外の場合はこれによってプラグインすべてが問題ではないことを切り分けられます。
2. 1 つのプラグインを有効化してテストします。
3. 問題が再発するまでステップ 2 を繰り返します。直近で有効化したプラグインを原因と見なすことができます。
4. ステップ 3 で特定したプラグインを除くすべてのプラグインを無効化して、ほかのプラグインとの組み合わせではなく対象のプラグイン自体が問題の原因であることを特定します。この場合、Atlassian Marketplace でプラグインの開発者に問い合わせるか、それがアトラシアン製のプラグインであった場合はアトラシアンに問い合わせます。

また、対象の Jira アプリケーションのバージョンに対してすべてのプラグインが有効かつ最新であることを確認します。互換性を持たないプラグインによって Jira アプリケーション インスタンスで問題が発生することは、よくあります。

サポートに情報を提供する

アトラシアン サポートではパフォーマンスの問題に取り組むときに、それらをトラブルシューティングするためにインスタンスの詳細情報を必要とすることがあります。このため、次の情報を提供してください。

1. Jira アプリケーションを実行しているサーバーのスペック (CPU/RAM/OS、アーキテクチャ/物理または仮想)
2. 対象のサーバーでほかに実行されているアプリケーション
3. データベース サーバーをほかに利用しているアプリケーション
4. エラーが発生しているブラウザとそのバージョン
5. 他のブラウザでも発生するかどうか
6. インスタンスのパフォーマンスが悪化している場合は問題が発生しているページ (いくつかのサンプル URL を提供してください)
7. インスタンスのパフォーマンスが悪化したタイミング (ログ調査のため)
8. Provide GC logs, as in JVM Configuration / Insufficient Memory.
9. Provide Access logs if using a Reverse-proxy, as in Reverse-proxy / Load-balancer.
10. The results of Disk Speed tests, as from that section.
11. Generate a Support ZIP and provide it along with the above information.