ガベージ コレクション (GC) のチューニング
Jira アプリケーションは、詳細なガベージ コレクション (GC) チューニングはあまり必要としない、堅牢なアプリケーションです。ただし、大規模なインストールでは、GC チューニングによって Jira アプリケーションのパフォーマンスを改善できる場合があります。また、GC ログの分析はパフォーマンスの問題のトラブルシューティングにも役立ちます。このページは、ガベージ コレクションを改善する基本的な推奨事項を示す、高度な GC チューニング ガイドの入門です。ここで案内する推奨事項は、大規模な Jira インスタンスのお客様におけるサポートの実際の成功に基づいています。
次のような場合、ガベージ コレクションについての知識が必要です。
- Jira のメモリまたは CPU 消費量が多い
- Jira の速度が遅い、または停止することがある
ガベージ コレクションのチューニング
GC パフォーマンスの確認
GC の改善に向けた最初の手順は、JVM の GC パフォーマンスを実際に測定して、問題の規模を確認することです。これは、GC ログを表示および分析して実行できます。ログでは、JVM がガベージ コレクションを行うタイミング、このプロセスの所要時間、開放されたメモリ量を確認できます。Jira 7.4 以降では、GC ログが自動的に生成されるようになりました。これらは <installation-directory>/logs で見つけることができます。GCViewer は GC ログを分析するための優れたツールです。以前の Jira バージョンでガベージ コレクションを有効化するには、「ガベージ コレクション ログの使用」を参照してください。
ガベージ コレクタ
アトラシアン サポートからの指示がない限り、Concurrent Mark Sweep (CMS) コレクタは使用しないようにしてください。このコレクタは手動による広範なチューニングとテストを必要とし、パフォーマンスを低下させる可能性があります。代わりに、Garbage First Garbage Collector (G1GC) の使用をお勧めします (特にヒープが 6 GB より大きい場合)。
ヒープ サイズ
最小のヒープから開始し、OutOfMemory エラーが生じた場合やメモリ関連の問題が発生した場合は割り当てを 512 MB または 1 GB 増やします。ガベージ コレクションに要する時間が長くなるため、必要以上にヒープを増やさないようにしてください。ガベージ コレクションの後、使用メモリは合計ヒープ サイズの 1/3 にする必要があり、これが目標です。
古いチューニング パラメーター
フル ガベージ コレクションのたびに、JVM は実際のスループットに応じて、Eden 領域や Survivor 領域などへの割り当てサイズを変更します。JVM は、作成、収集されるオブジェクトの実環境データに基づいて、自身のチューニングを行います。ほとんどの場合、JVM 自身にチューニングをまかせておく方がパフォーマンスが向上します。
過去に JVM パラメーターを追加したことがあり、現在 GC に問題が発生している場合、すべての GC 関連のパラメーターを削除するようお勧めします。ただし、特定の問題を解決するためにそのパラメーターを追加し、実際に問題が解決された場合は別です。また、パラメーターが今もその問題を解決していて、他の問題を引き起こしていないことを確認するために、今すぐ再ベンチマークの実行を検討する必要があります。
VM リソース
VM 上で Jira を実行する場合、スワップ ファイルを使用していないことを確認します。使用している場合は、JVM ガベージ コレクションの際にスワップ ファイルからオブジェクトをクリーンするためにメモリにロードする必要があり、これによって GC の一時停止が著しく長くなる可能性があります。スワッピングやバルーニング、バースティングを行うのではなく、VM に十分なメモリを割り当てます。
手動によるチューニング
以上の推奨事項を実施したあとも、GC の問題が継続していて、JVM チューニングの改善によりパフォーマンスを向上させることが可能かどうか確認したい場合は、ガベージコレクション（GC）チューニング ガイド の手順に従うことをお勧めします。このドキュメントでは、パフォーマンス目標 (スループット / フットプリント / レイテンシ) を選択するプロセスと、これらの目標を達成するためにチューニングする方法を説明しています。