ガベージ コレクターのパフォーマンス問題

本ドキュメントは Oracle の Hotspot JVM を使用したメモリ管理と大きな関連があります。これらの推奨事項は、大規模な Confluence インスタンスを使用する顧客をサポートした際の成功体験をもとにしています。

別途アトラシアン サポートから指示がない限り、 Concurrent Mark Sweep (CMS)コレクタを使用しないようにしてください。このコレクタは手動による広範なチューニングとテストを必要とし、使用によってパフォーマンスが低下する可能性があります。

小さなヒープの使用

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 などのツールを使用して、結果のログを表示します。

最終更新日 2014 年 9 月 2 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.