ガベージ コレクターのパフォーマンス問題
このページでは、Oracle の Hotspot JVM でのメモリ管理に関連する情報を説明します。これらの推奨事項は、大規模な Confluence インスタンスを持つお客様に対するサポート チームの成功事例に基づいています。
ガベージ コレクタの種類について
Confluence は既定でガベージ ファースト ガベージ コレクタ (G1GC) を使用します。これが推奨されるガベージ コレクタです。
このガベージ コレクタのチューニングの有用な情報については、Oracle ドキュメント｢Garbage First Garbage Collector Tuning｣でご確認ください。
G1GC はより大きなヒープ (2gb) でより優れたパフォーマンスを発揮することも確認されています。ヒープ サイズを徐々に大きくする方法については以下の情報を参照してください。
アトラシアン サポートからの指示がある場合を除き、Confluenceで Concurrent Mark Sweep (CMS) Collector は使用しないでください。このコレクタは手動による広範なチューニングとテストを必要とし、パフォーマンスを低下させる可能性があります。
適切なサイズのヒープの使用
OutOfMemory エラーが発生しない範囲で、できるだけヒープを小さく抑えます。OutOfMemory エラーが発生し、このヒープ値を大きくする必要がある場合、512 メガバイトまたは 1 ギガバイト単位で割り当てて、インスタンスを監視することをお勧めします。OutOfMemory エラーを受信し続ける場合は、もう 512 メガバイトまたは 1 ギガバイト増やし、OutOfMemory エラーが発生せず、安定した動作となるまで、このプロセスを繰り返します。ガベージ コレクションに要する時間が長くなるため、必要以上にヒープを増やさないようにしてください。
古いチューニングパラメーターの削除
フル GC を行うたびに、JVM は実際のスループットに応じて、 Eden 領域や Survivor 領域などへの割り当てサイズを変更します。JVM は作成、収集されるオブジェクトの実環境データに基づいて、自身のチューニングを行います。ほとんどの場合、単に JVM 自身にチューニングをまかせておく方がパフォーマンスが向上します。
過去に JVM パラメーターを追加したことがあり、現在 GC に問題が発生している場合、すべての GC 関連のパラメーターを削除するようお勧めします。ただし、特定の問題を解決するためにそのパラメーターを追加し、実際に問題が解決された場合は別です。また、パラメーターが今もその問題を解決していて、他の問題を引き起こしていないことを確認するために、今すぐ再ベンチマークの実行を検討する必要があります。
VM リソースの確認
VM 上で Confluence を実行する場合、スワップファイルを使用していないことを確認します。使用している場合は、JVM ガベージが収集を行う時に、スワップファイルからオブジェクトをメモリにロードする必要があり、これによって GC 一時停止時間が著しく長くなる可能性があります。スワッピングやバルーニング、バースティングを行うのではなく、VM に十分なメモリを割り当てます。
手動によるチューニング
推奨事項を実施した後も GC の問題が継続していて、JVM チューニングの改善によりパフォーマンスを向上させることが可能かどうかを確認したい場合は、｢ガベージ コレクション (GC) チューニング ガイド｣を参照してください。このドキュメントは数年前に製作されたものですが、パフォーマンス目標を選択 (スループット / フットプリント / 遅延) するための情報や、それらの目標を達成するためのチューニング方法が掲載されています。
GC ログの表示
ガベージ コレクション（GC）ログを有効にする方法 を参照し、Chewiebug の GCViewer などのツールを使用して、結果のログを表示します。