3

DSE 4.8.7 を使用すると、Solr によってインデックス付けされている cassandra テーブルに、1 秒あたり約 1,000 レコードを挿入できます。2 ～ 3 ノード (5 ノード クラスタ内) で次のメッセージがログに表示されるまで、しばらくの間 (おそらく 30 ～ 60 分) スループットは問題ありません。

INFO  [datastore.data Index WorkPool work thread-0] 2016-05-17 19:28:26,183  AbstractMetrics.java:114 - Cannot record QUEUE latency of 29 minutes because higher than 10 minutes.

この時点で、挿入スループットは 2 ～ 10 レコード/秒に低下します。ノードを再起動すると問題が解決します。クラスター内のすべてのノードで、OS 負荷と IO の両方が低くなっています。また、nodetool の統計を見ると、保留中のタスクはありません。

この質問は、(a) これがまだ問題であるように見え、(b) その質問についてコメントできないため、意図的に行っています。

4

1 に答える 1

0

ここに回答を投稿する価値があると思いましたが、次の質問にもほぼ同じ方法で回答しました。

n 分の QUEUE レイテンシーを記録できません - DSE

Solr ノードがレコードを取り込む場合、通常の Cassandra 書き込みパスに取り込む必要があるだけでなく、Solr 書き込みパスにもレコードを取り込む必要があります。Cassandra の圧縮は、Solr の同等の圧縮 (Lucene のマージ) と同様に行われています。圧縮とマージはどちらもディスク I/O で非常にコストがかかります。

デフォルトでdse.yamlは、設定max_solr_concurrency_per_coreはコメントアウトされています。これは、solr コア全体でインデックス作成に割り当てられているスレッドが多すぎることを意味する可能性があります。

上記のブログで @phact によってリンクされた投稿は、実際に開始するのに適した場所です。IndexPoolmBeanの監視は、チェックを開始するのに適した場所です。をチェックしてQueueDepth、増加しているかどうかを確認します。増加している場合は、ノードがインデックス作成のスループットに対応できず、CPU と I/O を調べる時間がありません。CPU の使用率が高くない場合は、同時実行数を増やすことをお勧めします。

大規模なクラスターでは、通常、Cassandra ノードを備えた DC で高速の取り込みが行われ、独自の DC 内の Solr ノードにレプリケートされます。このようにワークロードを分割することも、検討に値する可能性があります。

もう 1 つのことは、インデックスのサイズでもありますomitNorms=true。スキーマに設定してテキスト フィールドなどのサイズを小さくすると、インデックスのサイズも大幅に縮小できます。

私はあなたを助けるかもしれないいくつかのドキュメントのリンクをここに投稿します。

https://docs.datastax.com/en/datastax_enterprise/4.8/datastax_enterprise/srch/srchTune.html

https://docs.datastax.com/en/datastax_enterprise/4.8/datastax_enterprise/srch/srchCmtQryMbeans.html

于 2016-10-13T17:09:22.223 に答える