G1GCが古い世代をクリーンアップしていない
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/2qh8yjqbtcvg0y29ll9wf5zq7ofkmf09 into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
こんにちは、
Solr Cloud 9.1.1をSolr Cloudクラスタで使用しています。初期ヒープサイズは12GBのうち約400MBを使用します。いくつかのクエリを実行すると、ヒープが8GBまで増加します。そして、コレクションをリロードすると7GBに減少します。このケースではG1GCを使用しています。
同じテストケースをZGCで実行すると、ヒープは1GB未満に減少します。
よろしくお願いします
Bilal
これが有効な比較であるためには、コレクションをリロードするだけでなく、フルGCをトリガーする必要があります。Solr自体は、手動でGCをトリガーすることは決してありません。カスタムプラグインを追加するか、カスタムバージョンのSolrをコンパイルする必要があります。
G1GCは、新世代（New Generation）のクリーンアップに重点を置きます。古世代（Old Generation）のガベージを収集するには、フルGCが実行される必要があります。G1GCは、絶対に必要でない限りフルGCを行わないように設計されています。12GBのうち8GBが使用中である場合、フルGCなしでも十分な空きメモリがあり、そのため古世代には何も行われません。
割り当てられたヒープが最大（この場合12GB）に近づくと、G1はフルGCを行います。その際、フルGCは遅く、完了するまでSolrが停止します。8GBのヒープで、G1GCがフルGCを行う際に、アプリケーションが最大15秒間停止するのを見たことがあります。
ZGCがどのように機能するかについてはほとんど知りませんが、いくつかの実験を行ったところ、gceasy.ioの分析によれば、G1よりもはるかに多くのコレクションを行いますが、各コレクションは非常に高速であり、その結果、個々のポーズが非常に短いことがわかりました。あなたの結果から判断すると、ZGCはインクリメンタルランで両世代をクリーンアップしているようです。
よろしくお願いします
Shawn
こんにちは、Shawn
G1GCを使用してファセットクエリを実行していると、SolrがOOM（メモリ不足）でクラッシュし、GCがトリガーされません。
すべてのキャッシュはsolrconfig.xmlで無効にしています。
よろしくお願いします、
Bilal
JavaのOutOfMemoryError例外は、メモリ不足以外のリソースが枯渇した場合にも発生することがあります。実際にどのリソースが枯渇したのかを特定しないと、間違った問題を追いかけてしまう可能性があります。
Solr 9.1.1は、必ずしも実際のOOME（メモリ不足例外）をログに記録しないことがあります。Solr 9.2.0以降では、OOMEが発生した際にスクリプトを実行する代わりに、Java自体がクラッシュし、そのクラッシュログにJava自体が理由を記録します。
OOMEの原因が分かれば、次のステップに進むことができます。OOMEに対処する方法は、以下の2つしかありません。
1) 枯渇したリソースの量を増やす。
2) 設定を変更するか、ソフトウェアを修正して、そのリソースの必要量を減らす。
よろしくお願いします、
Shawn
トピックへ返信するには、ログインが必要です。