あなたが説明している動作と使用しているバージョンに基づくと、次のリンクを確認する価値があるかもしれません：
https://issues.apache.org/jira/browse/SOLR-13336

Thank you Michael, I will investigate this.
Michaelさん、ありがとうございます。これを調査します。
Dominique

いくつかの用語の意味がよくわからないです。

各色が表すCPUの特性は何ですか？特に濃い紫色はどういう意味ですか？画像にその情報がありません。

ERRORログはどうですか？または他の重大度のログはありますか？solr.logを見て、問題が発生した時や終了した時に処理されていたリクエストを確認しましたか？Solr以外のソフトウェアは同じマシン上にありますか？問題が発生している間にマシンのパフォーマンス情報（たとえば*NIXの場合はtop、Windowsの場合はリソースモニターなど）を確認しましたか？

10:40から10:50の間に何を始めたか尋ねましたか？クエリ数や更新リクエスト数など、その他のパフォーマンスグラフはありますか？ディスク使用率やJavaメモリの特性など。

CPUのグラフだけでは問題の原因を特定するのは難しいですね。

問題が再発するかどうかは？もしそうでなく、そのCPUグラフがそのイベントから持っているすべてであれば、根本原因を突き止めることはできないかもしれません。

ありがとうございます。
Shawn

インデックス作成速度の平均は秒間100件で、自動コミットは5分ごとに行われ、自動ソフトコミットは1分ごとに行われています。
検索の平均クエリ数は秒間1000件です。

各色は1つのSolrサーバーのユーザーCPU使用率を表しています。サーバーはLinuxであり、Solr専用です。

ログレベルはWARNで、WARNログには有益な情報は提供されていません。ログにはERRORログはありません。

顧客からは特筆すべきことは何も始まっていないとの報告がありました。単に通常のインデックス作成と検索が行われています。

これは現時点で唯一のグラフです。特異な点は、1つのサーバーだけが30分間にわたってユーザーCPU使用率が100%に増加し、時折1〜2分間、そのCPU使用率が低下する一方で他のサーバーのCPU使用率が増加することです。情報が限られていますが、私の質問は「このようなユーザーCPU監視パターンに遭遇したことがあり、その原因についてのアイデアを持っている方はいますか？」というものでした。

非常に高いクエリレートですね。ほぼ間違いなく、2つのレプリカでは十分ではないでしょう。

性能の壁にぶつかっている可能性が高いです。これはSolrを含むバックエンド処理システムにおける非常に一般的なパフォーマンス現象です。Xでは問題ないが、X+1では性能が著しく低下するという状況です。

おそらく、各シャードのレプリカを少なくとも3つにする必要があるでしょう。長期的には3つのレプリカでも足りないかもしれません。

標準のNRTレプリケーションに依存していますか、それともTLOGに切り替えましたか？2つのレプリカではPULLをまったく使用しないでください。

TLOGレプリカに切り替えることで、性能が改善する可能性がありますが、非常に高いクエリ負荷に対応するためにはさらに多くのレプリカが必要になるでしょう。インデックスがより良くキャッシュされるようにメモリを追加することも試してみることができますが、メモリを追加するよりもサーバーを追加する方がコスト効率が良いことがクラウドサービス（例えばAWS）ではしばしばあります。10億のドキュメントを扱う場合、非常に多くのメモリが必要です。また、そのような大きなインデックスで大規模なマージが数時間かかることがあり、CPUに対してI/Oよりも影響が大きいです。

そのような大きなインデックスでは、autoSoftCommitのmaxTimeが1分では短すぎる可能性があります。soft commitが実際に行われるまでにどれくらい時間がかかるのか調査する必要があります。autoCommitの時間はおそらく問題ないでしょうし、openSearcherがfalseに設定されている限り、大幅に短縮することができるかもしれません。特にautoSoftCommitを使用する場合、openSearcher=falseの使用が強く推奨されます。通常、autoSoftCommitのインターバルはautoCommitのインターバルよりも大きくする方が良いです。

ありがとうございます。
Shawn