Jira サーバーでのパフォーマンスの問題のトラブルシューティング
プラットフォームについて: Server および Data Center のみ。この記事は、Server および Data Center プラットフォームのアトラシアン製品にのみ適用されます。
Server* 製品のサポートは 2024 年 2 月 15 日をもって終了します。Server 製品を利用している場合は、Atlassian Server のサポート終了のお知らせページにて移行オプションをご確認ください。
*Fisheye および Crucible は除く
トラブルシューティングを行う前に、ご利用の Jira アプリケーションが適切なサポート対象のプラットフォームで実行されていて、Jira アプリケーションのインストール要件が満たされていることをご確認ください。
概要
パフォーマンスの問題のトラブルシューティングは簡単なプロセスではなく、Jira アプリケーションの問題を特定する際には非常に複雑になる場合があります。さまざまなバージョン、プラグイン、ネットワーク、ハードウェア構成、その他のさまざまな要素などの、Jira アプリケーションで考えられる構成の数を考慮すると、このような問題の解決はさらに困難になります。このナレッジベース記事は、この作業を簡単に行えるようにし、問題を特定したりサポートに情報を提供したりするためのガイダンスを提供することを目的としています。
パフォーマンスの問題のトラブルシューティングでは多くの場合、1 つ以上の症状について原因を 1 つずつ切り分け、それが根本原因であるかどうかを検証することになります。これをディスカバリ (インスタンスの診断情報の収集) で行い、次にその情報を分析して問題を特定できるかどうかを確認します。この作業では多くの場合、何か小規模の変更を行い、その変更がインスタンスの安定性に影響するかどうかをテストします。これはインスタンスの複雑性 (プラグイン、ハードウェア構成など) の複雑性によっては時間がかかる可能性があります。
よく使われる用語
| 用語 | 説明 |
|---|---|
| Java Virtual Machine (JVM) | Java Virtual Machine (JVM) は、Java アプリケーションのコンパイル済みバージョン (バイトコード) を実行できる、仮想マシンです。これによってクロスプラットフォーム機能が実現されます。JVM は、Jira アプリケーションを駆動する Java プラットフォームのコードを実行する構成要素です。 |
| ガベージ コレクション (GC) | コンピューター サイエンスの領域では、ガベージ コレクション (GC) は自動的なメモリ管理の形式です。ガベージ コレクター、あるいは単にコレクターは、プログラムによって使われなくなった、オブジェクトが所有していたメモリ (ガベージ、ごみ) の再取得を試みます。これは JVM によって自動的に完了されます。 |
| OutOfMemoryError (OOME) | これは、Java Virtual Machine がメモリ不足のためにオブジェクトを割り当てられず、ガベージ コレクターによって提供可能なメモリもこれ以上ない場合に返されます。これはさまざまな問題を発生させる可能性があります。これが返された場合は JVM が不安定な状態にある可能性が高いため、Jira アプリケーションを可能な限り迅速に再起動することが推奨されます。 |
| 例外 | 例外はプログラムの実行中に発生するイベント (多くの場合はエラー) であり、対象のプログラムの通常のフローを破壊します。たとえば NullPointerException は、Jira アプリケーションで |
| スタック トレース | スタック トレース (スタック バックトレース、スタック トレースバックとも呼ばれます) は、プログラムの実行中の特定のタイミングでの、アクティブなスタック フレームのレポートです。一般に、インタラクティブなデバッグやポストモーテムのデバッグで利用されます。エラー メッセージの一貫としてプログラムのユーザーに表示し、ユーザーがプログラマーに報告できるようにすることもできます。 |
| スレッド ダンプ | ダンプの取得時点でさまざまな Java スレッドすべてが行っている処理のダンプであり、すべてのスレッドのその時点での状態のブレイクダウンが提供されるため、Java アプリケーションの問題の原因を特定するために利用できます。これらは、システムで問題発生しているとき (Jira アプリケーションのロックアップ、ハング、速度遅延) に作成された場合にのみ有益です。 |
| ヒープ ダンプ | ご利用の Jira アプリケーションのメモリ内のすべてのオブジェクトのコンテンツのダンプです。ヒープ ダンプの作成時における。メモリ内のすべてのオブジェクトのブレイクダウンが含まれるため、JVM が OutOfMemory エラーを返している原因を特定するのに利用できます。スレッド ダンプと同様に、OOME が返されているタイミングのもののみが有益です。 |
Jira アプリケーションのハードウェア構成
Jira のソフトウェア構成
症状
ブラウザで、Jira アプリケーションの応答や読み込みが全体的に遅い。
アプリケーションのバグ (Jira、JVM、カーネル/OS)
Jira アプリケーションが応答を返さない。
アプリケーションのバグ (Jira、JVM、カーネル/OS)
CPU 利用率が極端に増える (80-100 % の利用率)
アプリケーションのバグ (Jira、JVM、カーネル/OS)
OutOfMemoryError による Jira アプリケーションのクラッシュ
- OutofMemory Java ヒープ スペース エラーが発生して Jira サーバーがクラッシュする
- GC overhead limit exceeded エラーによって Jira Server がクラッシュする
アプリケーションのバグ (Jira、JVM、カーネル/OS)
基盤となるコネクション プールからコネクションを取得できない
Jira サーバーで処理に失敗し、ログにコネクション プールのエラーが記録される
このステップを進めるには、それぞれのよくある問題を 1 つずつ確認し、それが症状の原因であるかどうかを切り分けてください。
ネットワークの接続性
ネットワークやサーバーに問題が発生していないかどうかを、システム管理者/ホスティング プロバイダーに確認します。これは、Jira アプリケーションが実行されているポートでサーバーに ping や telnet を送信することでも行えます。例:
ping 192.168.1.123
telnet 192.168.1.123 8080Telnet は、ファイアウォールが対象のポートをブロックしているかどうかを確認するために利用できます。http://just-ping.com/ などのツールは、地域固有の遅延の問題を診断するために利用できます。包括的な分離テストを行うには、サーバーをローカル ネットワークに接続してネットワークの問題が発生するかどうかを確認します。
アプリケーション
アプリケーションが起動している (Tomcat プロセスが実行されている) かどうかを確認します。
- Review the logs to see if there are any errors or exceptions and stack traces. Check https://jira.atlassian.com, the Jira Server, Jira Core and Jira Service Desk Document Archives and Google for those Exceptions/errors.
- 「スレッド ダンプの生成」ドキュメントに従い、10 秒間隔で 3 つのスレッド ダンプを分析用に取得します。これにより、インスタンスのロックアップ時の発生内容のブレイクダウンを確認できます。
スレッド ダンプを分析すると、アプリケーションのロックアップ要因を確認できる場合があります。スレッド ダンプは、アプリケーションの失敗または低速なパフォーマンスの最中に取得された場合にのみ有益です。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
また、次の内容をご確認ください。
- [管理] > [システム] > [トラブルシューティングとサポート] > [ロギングとプロファイリング] でプロファイリングを有効化してテストを行うと問題を特定できる場合があります。
- また、「jProfiler を利用して Jira アプリケーションのパフォーマンスを分析する」ナレッジベースに従い、jProfiler を利用してインスタンスのプロファイルを行うと、もっとも応答に時間がかかっているクラスやメソッドの正確なブレイクダウンが得られます。
リバース プロキシ/ロード バランサ
リバース プロキシ/ロード バランサを利用している場合、それを迂回してインスタンスに直接アクセス (例: http://192.168.1.123:8080/jira) し、違いが出るかどうかを確認してみます。
「SSL を使って Jira アプリケーションを Apache に連携する」に従って Tomcat がプロキシ コネクタとしてセットアップされている場合、これは動作しません。
Jira HTTP Requests Log Analyzer を利用してアクセス ログを分析すると、インスタンスが過負荷になっているかどうかを診断できます。この場合、応答時間が増え、それらのログも原因の特定に役立ちます。
ハードウェア リソース
- Jira のアプリケーション要件が実現されていることを確認し、Jira アプリケーションの CPU 負荷が高いかどうかを確認します。CPU が別のプロセス (または Jira アプリケーション) によって消費されていると、応答に時間がかかる可能性があります。
- 1 つのサーバーに複数のアプリケーションがある場合、すべてのアプリケーションに十分なリソースがあることを確認します。JVM に要求されるリソースを計算するには、permgen に最大ヒープ サイズを追加し、JVM 用に 128 MB を追加します。例:
| アプリケーション | 最大メモリ (Xmx) | PermGen | JVM オーバーヘッド | 合計 |
|---|---|---|---|---|
| Jira | 1024 | 256 | 128 | 1408 |
| Confluence | 1536 | 256 | 128 | 1920 |
アプリケーションがインストールされているサーバーの場合、これら 2 つのアプリケーションを提供するのに 3328 MB が要求されるほか、オペレーション システム用のオーバーヘッドを追加する必要があります。マシンでは最小でも 4 GB が利用可能である必要があり、マシンは 64 bit である必要があります。また、同じサーバー上のほかのアプリケーション (データベースなど) の要件も考慮するようにします。
Jira アプリケーションや他の JVM アプリケーションが をホストしているサーバーが 32 bit で実行されている場合の既知の問題があります。詳細については「Windows サービスとして実行されているときに Jira がクラッシュする」ナレッジベースをご確認ください。
ブラウザのパフォーマンスの問題
別のブラウザを使い、レスポンスに違いが発生するかどうかを確認します。IE (特に IE 8) は一般にコンテンツのレンダリングが Chrome よりも大幅に遅くなります。問題の診断の詳細については「クライアントサイドのブラウザの問題のトラブルシューティング」ナレッジベースをご確認ください。
ブラウザの問題の分離テストは、クロスブラウザでのテストを行うことです。ブラウザを横断して問題が継続している場合、サーバー側のパフォーマンスである可能性があります。
インスタンスまたはサーバーのキャパシティ上限/利用超過
- これは多くの場合はデータベースの統計情報 (課題、カスタム フィールド、ワークフロー、ユーザー、セキュリティ スキームなど) や Jira アプリケーションのバージョンに依存するため、1 つですべてを網羅できるようなルールはありません。アトラシアン サポートにサポート zip を提供すると、インスタンスについての大まかな推奨事項をご案内することができます。アップグレードが必要だったり、バージョンに対してインスタンスが大きすぎたりする可能性があります。
- アクセス ログを収集して確認し、インスタンスで高負荷が発生しているかどうかを確認します。
- SOAP または REST を利用している外部アプリケーション連携がインスタンスを過負荷にしているかどうかを確認します。
- テスト サーバーを最新バージョンにアップグレードしてそこに本番環境を復元すると、パフォーマンスの問題がアップグレードで解決されるかどうかを特定できます。
Jira HTTP Requests Log Analyzer を利用してアクセス ログを分析すると、インスタンスが過負荷になっているかどうかを診断できます。この場合、応答時間が増え、それらのログも原因の特定に役立ちます。
ディスク速度
ディスク I/O が悪いと、検索、ガジェット、10 個以上の添付ファイルを持つ課題でパフォーマンスが悪化します。「ディスク アクセスの速度をテストする」ナレッジベースのツールや手順を利用してディスク速度を確認し、その結果を良/悪/平均の範囲と比較してみます。
アンチウイルス ソフトの「オンアクセス」は Jira アプリケーションとの相性が悪く、インデックス ディレクトリはオンアクセス スキャンから除外する必要があります。Symantec の特定のバージョンなどの一部の例ではこの例外が無視され、問題が継続します。このような場合はサーバーからアンチウイルス ソフトをアンインストールして別のソリューションを検討する必要がある場合があります。
Linux 環境の場合、noatime でファイルシステムをマウントするのを検討します。これは、ファイルの読み取り時にタイムスタンプを設定しないように OS に指示します。アプリケーションが Lucene インデックスやキャッシュ ファイルに、1 秒間に何千回もアクセスすると、atime の書き込みによってパフォーマンスが明確に悪化することがあります。ある事例によると、最大で 30 % の悪化が見られます。マウント オプションを変更する前に、atime に依存しているアプリケーションがほかにないことを確認する必要があります。同じようにメリットを提供する、より保存的な設定として、"relatime" があります。詳細については「Gain 30% Linux Disk Performance with noatime, nodiratime, and relatime」をご確認ください。
データベース
- データベースと DB サーバーの負荷を確認します。「Jira Server のデータベースのパフォーマンスをテストする」ナレッジベースを利用できます。なお、アトラシアン サポートはデータベースの問題の診断やトラブルシューティングの専門家ではないため、この問題は対象のサーバーの DBA に報告する必要があります。
- 「コネクションのクローズに対応する」に従って
validationQueryが設定されていて、「Jira アプリケーションをデータベースに接続する」ドキュメントに従ってデータベース コネクションが構成されているのを確認します。
適切なバージョンのドキュメントに従うことが非常に重要です。誤ったバージョンの誤ったパラメーターを使うと、DB コネクションで大きな問題が発生する可能性があります。
既知の問題
- JRA-9979 - Getting issue details... STATUS - Jira 5.2 よりも前では、notificationinstance が大きなサイズに成長する可能性があります。この場合に Jira がこれらのテーブルにアクセスすると、それはデータベースと Jira の間の応答時間を大幅に低下させます。このテーブルをクリアするとパフォーマンスが戻ります。
JVM 構成/不十分なメモリ
- 最近 Jira アプリケーションのアップグレードを行いましたか? その場合、以前の JVM 構成が古いバージョンから移行されているかどうかを確認します。
- OOME が発生している場合、「Jira アプリケーションのメモリを増やす」に従って最大メモリを少しずつ (256 MB) 増やし、問題が引き続き発生するかどうかを確認します。
- Jira アプリケーションが利用している JVM メモリでの発生内容を分析するにはガベージ コレクションのログが必要です。これは「Jira Server のパフォーマンスを GC ログでトラブルシューティングする」ナレッジベース記事に従って有効化できます。
- 「Jira サーバーの OutofMemory エラーをヒープ ダンプで分析する」ナレッジベースに従い、OOME が返されたときにヒープ ダンプを自動的に生成するように JVM をセットアップします。
- ログに CodeCache 警告があるかどうかを確認します。詳細については「完全な CodeCache によって Jira がクラッシュするかパフォーマンスが低下する」をご確認ください。
Java の VisualVM をインストールして、Jira アプリケーションを実行しているプロセスをバインドするために使用できます。これを使用して、GC による CPU 使用状況やヒープの使用状況を分析できます。各ヒープ領域の視覚的な情報を提供する visualGC プラグインのインストールが推奨されます。
- GC ログの分析と、インスタンスの低速時との比較は、メモリの問題の切り分けに最適です。たとえば、インスタンスのパフォーマンスが特定のタイミングで遅い場合、そのタイミングで完全な GC が発生しているかどうかを確認します。これはアプリケーションの応答時間を低下させる可能性があります。
- CPU スパイクが発生している場合、完全な GC が一貫して行われているかどうかを確認します。ガベージ コレクションは CPU を消費します。JVM に提供されているメモリが不足している場合、より多くの GC サイクルが必要になるため、CPU の利用量が増えます。JVM に適切なメモリがあることを確認します。これが原因であるかどうかを切り分けるには、メモリを少量ずつ増やします。
GCViewer などのツールは、GC ログの分析に非常に便利です。
アプリケーションのバグ (Jira、JVM、カーネル/OS)
Check jira.atlassian.com, the Jira Server, Jira Core and Jira Service Desk Document Archives and also the DB/OS/Java vendor to see if there are any bugs that present with performance symptoms. Some examples of OS bugs that have crippled JIRA application performance:
- khugepaged eating 100%CPU
- Linux glibc >= 2.10 (RHEL 6) malloc may show excessive virtual memory usage
プラグイン (サードパーティまたはバンドル)
アトラシアンではサードパーティ製プラグインのサポートは提供しません。Atlassian Marketplace でプラグイン ベンダーの詳細情報を確認して直接問い合わせるか、アトラシアン コミュニティで質問を投稿して支援を依頼してください。
特にサードパーティまたはインハウス (内製) のプラグインは、Jira アプリケーションでさまざまな問題の原因になることがあります。DBCP やメモリ (ヒープ利用率) を消費したり、課題の処理を遅延させたり、他のさまざまな問題を発生させることがあります。ベスト プラクティスとして、プラクティスが 1 つも有効化されていない状態でパフォーマンスの問題が引き続き発生するかどうかを確認します。UPM でセーフ モードを有効化することで、プラグインが問題かどうかを確認できますが、インスタンスの機能が減らされるために影響が発生する可能性があります。これは業務に影響を与える可能性があるため、本番環境と同一の複製されたテスト インスタンスでこの操作を行うことをおすすめします。これは次のような分離テストでも行えます。
- セーフ モードを有効化して問題が再現可能かどうかを確認します。再現されない場合、プラグインによって遅延が発生している可能性があります。問題が再現されなくなったら以降の手順を続けます。それ以外の場合はこれによってプラグインすべてが問題ではないことを切り分けられます。
- 1 つのプラグインを有効化してテストします。
- 問題が再発するまでステップ 2 を繰り返します。直近で有効化したプラグインを原因と見なすことができます。
- ステップ 3 で特定したプラグインを除くすべてのプラグインを無効化して、ほかのプラグインとの組み合わせではなく対象のプラグイン自体が問題の原因であることを特定します。この場合、Atlassian Marketplace でプラグインの開発者に問い合わせるか、それがアトラシアン製のプラグインであった場合はアトラシアンに問い合わせます。
また、対象の Jira アプリケーションのバージョンに対してすべてのプラグインが有効かつ最新であることを確認します。互換性を持たないプラグインによって Jira アプリケーション インスタンスで問題が発生することは、よくあります。
jProfiler を使用した OOME またはメモリ使用率のヒープ ダンプの確認 (jProfiler を使用して Jira アプリケーションのパフォーマンスを分析する) や VisualVM は、特定のプラグインが大量のヒープを使用しているかどうかを特定するのに適切な方法です。スレッド ダンプにより、ロックアップ中にプラグインが問題を発生させているかどうかを確認できます。ただし、これらは明確な分離テスト用の代替案ではありません。
サポートに情報を提供する
アトラシアン サポートではパフォーマンスの問題に取り組むときに、それらをトラブルシューティングするためにインスタンスの詳細情報を必要とすることがあります。このため、次の情報を提供してください。
- Jira アプリケーションを実行しているサーバーのスペック (CPU/RAM/OS、アーキテクチャ/物理または仮想)
- 対象のサーバーでほかに実行されているアプリケーション
- データベース サーバーをほかに利用しているアプリケーション
- エラーが発生しているブラウザとそのバージョン
- 他のブラウザでも発生するかどうか
- インスタンスのパフォーマンスが悪化している場合は問題が発生しているページ (いくつかのサンプル URL を提供してください)
- インスタンスのパフォーマンスが悪化したタイミング (ログ調査のため)
- 「JVM 構成/メモリ不足」に従って GC ログを提供してください
- 「リバース プロキシ/ロード バランサ」に従い、リバース プロキシを利用している場合はアクセス ログを提供してください
- 対象のセクションに従い、ディスク速度テストの結果
- サポート zip を生成し、上記の情報とともに提供してください