インデックス作成時の非常に高いCPU使用率
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/v7gnb76c3k2lz0fnwxxl3b71h6lcjhh5 into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
こんにちは皆さん、
テスト環境として使用している2つのSolr 8.11ノード（クラウドモード）と1つのZookeeperノードのクラスターを持っています。サーバーはAmazon EC2上にあり、t3.xlarge（4コア、16GBのRAM）を使用しています。ヒープサイズは8GBに設定されています。
これらを数ヶ月前にインストールして以来、すべてが非常にうまく機能していました。6つの異なるコレクションがあり、それぞれに約1100万件のレコードがあります（各コレクションはテスト環境の1つに対応しています）。インデックス作成と検索は高速で、トラフィックもあまりありません。しかし、突然、昨日から非常に高いCPUスパイク（主なSolrプロセスが最大400％のCPU使用率）を経験し始めました。これにより、検索が遅くなり、インデックス作成時には信じられないほどの遅延が発生しています。例えば、レコードをインデックスに追加すると、それらのレコードが検索で利用可能になるまでに約10分かかります。私たちのコミット戦略は、ハードコミットが60秒ごと、ソフトコミットが1秒ごとです。
私の知る限りでは、これらのサーバーに何もインストールしていません。両方のノードを再起動してみましたが、同じ問題が続いています。私はSolrとSolrCloudの初心者で、特にサーバーの保守に関してはあまり経験がありませんので、何をすべきか、またはどの情報を提供すべきかがわかりませんが、どんな助けでもありがたいです。
この問題が発生する前に、t3.largeインスタンス（2コア、8GBのRAM、ヒープサイズ4GB）を使用していましたが、CPUスパイクがSolrプロセスをダウンさせることがあったため、アップグレードを決定しました。
事前にどんな助けでも感謝します。
Matias Laino
そうしないでください。コミットが完了するまでに1秒以上かかる可能性が高いため、autoSoftCommitを1秒に設定していると、同時に多数のコミットが発生しようとします。これが問題の原因だと思われます。この問題は雪だるま式に制御不能になる傾向があります。
autoSoftCommitを1秒に設定している場合、更新が反映されるまでに10分かかるというのは、コミットに1秒以上かかっていることを示しており、コミットの頻度を減らす必要があります。
一般的に、autoSoftCommitのmaxTimeはautoCommitの設定値の少なくとも2倍であるべきです。ドキュメントの変更が1秒で表示されることを期待するのは非現実的です。
autoCommit設定では、openSearcherをfalseに設定すべきです。
autoCommitやautoSoftCommitでmaxDocsを使用しないことをお勧めします。maxTimeの設定の方がはるかに予測可能です。
コミット問題を悪化させる他の可能性としては、6600万件のドキュメントには、良好なパフォーマンスを得るために4GB以上のヒープサイズが必要かもしれません。また、ディスク上のインデックスデータのサイズが残りの4GBのメモリに収まることは非常に稀です。システムがインデックスデータを効果的にキャッシュできない場合、パフォーマンスはひどくなります。一般的に、8GB以上のメモリが必要です。
https://cwiki.apache.org/confluence/display/solr/solrperformanceproblems
ありがとうございます。
Shawn
ありがとう、Shawn。これらの推奨事項を確かに確認しますが、過去3か月間問題なく動作していて、突然この問題が発生し始めた理由が説明できません。
私たちのアプリケーションでは、レコードが作成された際にそのレコードが即座に検索で利用可能であることを顧客が期待しています（そのためにautoSoftCommitを1秒に設定しています）。このような状況では、どのような推奨事項がありますか？
これが現在の設定です：
<autoCommit>
<openSearcher>false</openSearcher>
<maxTime>60000</maxTime>
</autoCommit>
<autoSoftCommit>
<maxTime>1000</maxTime>
</autoSoftCommit>
Matias Laino
3ヶ月前と比べて、インデックスのサイズはどうなっていますか？ 各Solrノードにどれくらいのインデックスデータがありますか？ 総ドキュメント数はどれくらいですか？ 元のメッセージからすると、約6000万件だと思いますが、各コレクションのディスク上のサイズとドキュメント数（最大ドキュメント数、実際のドキュメント数ではない）を教えていただけると助かります。
まず、autoCommitを15000に下げて、autoSoftCommitを60000に上げることをお勧めします。前述したように、インデックスが非常に小さくない限り、1秒のレイテンシーを期待するのは現実的ではありません。総ドキュメント数が6000万件を超える場合、それを小さいとは呼べませんが、もっと大きなインデックスを持つユーザーもいます。
インストールからGCログを収集して提供できますか？ それが多くの質問に答えることができます。
前回送ったWikiの記事には、プロセスリストのスクリーンショットを取得する方法についてのセクションがあります。 それを取得して提供できますか？
その情報から得たものによっては、さらに質問があるかもしれません。
ありがとうございます。
Shawn
こんにちはShawn！
再び返信してくれてありがとうございます。いくつかの質問に対する回答です。
Q: 3ヶ月前と比べてインデックスのサイズはどう変わりましたか？
A: ほとんど同じです。Websolrを何年も使用していましたが、パフォーマンスの問題が多く、高価でした（サービスが頻繁にダウンしました）。そのため、v4.10から自前の8.11 SolrCloudクラスターに移行しました（テスト環境はLucene Matchバージョン7.1.0を使用しています）。コレクションは最大でも約100万レコード増えたかもしれませんが、それほど増えていないと思います。
Q: 各Solrノードにどれくらいのインデックスデータがありますか？
A: 総ドキュメント数と同じだと思いますが、違うかもしれません。各ノードに68.6百万件のデータがあります。
Q: 総ドキュメント数はどれくらいですか？
A: ダッシュボードに基づくと、各ノードに68.6百万件のドキュメントがあります（同じデータを複製しています）。
Q: 各コレクションのディスク上のサイズとドキュメント数（最大ドキュメント数、実際のドキュメント数ではない）を教えてください。
A: メトリクスからどこでこれを取得するかはわかりませんが、クラウドダッシュボードに基づくと、シャードごとに以下のようになっています：
- preview_s1r2: 1.9Gb
- preview_s2r11: 1.9Gb
- preview_s2r6: 1.9Gb
- staging-d_s1r1: 1.8Gb
- staging-d_s2r4: 1.8Gb
- staging-a_s1r1: 1.7Gb
- staging-a_s2r4: 1.7Gb
- staging-c_s2r5: 1.6Gb
- staging-c_s1r2: 1.6Gb
- pre-prod_s1r1: 1.6Gb
- pre-prod_s2r4: 1.6Gb
- staging-b_s1r2: 1.5Gb
- staging-b_s2r5: 1.5Gb
これは他のノードにも複製されています。
これを試してみます。Solrのドキュメントから理解したところでは、NRTの場合、autoSoftCommitはautoCommitよりも低く設定する必要があります。ハードコミットはより高価な操作だからです。autoSoftCommitを15000にしてautoCommitを60000にすべきでしょうか？基準として、データをインデックス化した際に「ほぼ即時」に利用可能である必要があります。検索のためにSolrを使用しているので、新しいレコードを追加した際にほぼ即座に検索で利用可能である必要があります。このためにはどの設定が最適かはわかりませんが、以前から述べた設定を長い間使用してきました（Websolrでは個別の「インデックス」を使用しており、異なるサーバー上にあったかどうかはわかりませんが、これらのサーバーのメモリ量についての情報は持っていません）。
GCログについては、以下のリンクから各ノードの.0ファイルを参照できます：
プロセスリストについては、以下のリンクから参照できます：
この件に関して再度ご助力いただき、本当にありがとうございます！
Matias Laino
トピックへ返信するには、ログインが必要です。