2

何らかの理由で、Cassandra ノードに高い負荷がかかります。画像を取得するための情報をいくつか示します。

  • まったく新しいクラスターを作成すると、負荷は数日間常に低くなり、時間とともに増加し、1 週間後または何かが空中に移動し、クラスター全体が不安定になることがわかりました。

  • 約 300 ～ 400 MB のデータを含むキースペースの 1 つのスナップショットを 4 時間ごとに作成し、7 日以上経過したキースペースを削除しています。すべて OpsCenter で構成されています。

  • クラスターは、Microsoft Azure のストライプ化されたディスクで実行されています

  • ノードは 3.5 GB の RAM を搭載した 2 コアで実行されています。これが推奨されるハードウェアよりも低いことは十分承知していますが、これが高負荷の原因ではないはずです。7 GB の RAM を搭載した 4 コアで実行してみました。違いは見られなかった

おそらく、高負荷を引き起こす可能性のあるもののボックス全体があると確信していますが、何か他のものよりも可能性が高いと思います.

ここに画像の説明を入力

編集

この高負荷は、OpsCenter の修復サービスが原因であると思われます。サービスによる修復の実行方法を調整するには、いくつかの設定が必要です。

4

1 に答える 1

5

[repair_service] セクションを opscenterd.conf に追加することで、修復サービスを構成できます。

チューニングの主な手段は次のとおりです。

max_parallel_repairs = 0

必要な時間内 (< gc_grace_seconds) に修復が完了するまで、これを増やすことができます。

min_repair_time = 5

データがそれほど多くない場合、修復サービスの完了が早すぎて再起動し、不要なオーバーヘッドが発生する可能性があります。この値を増やして、修復を頻繁に実行しないようにすることができます

snapshot_override

繰り返しますが、データがあまり多くなく、修復サービスの完了が速すぎる場合は、生成されるスナップショットが多すぎます (既定では、修復サービスはすべての修復の前にスナップショットを作成します)。スナップショット ディレクトリがすぐにいっぱいになる場合は、サービスを 1 回だけ実行するように調整するまで、これをオフにすることをお勧めします (raise min_repair_time drop parallel_repairs を使用します)。

注:修理サービスのポイントは、高価でリソースを消費する修理プロセスを小さなジョブに分散することです。これは、全体的な CPU 使用率をスパイクして影響を与えるのではなく、常に 5% または 10% 増加させることができることを意味します。定期的な修復実行中のワークロード。

高度な構成の詳細

于 2015-01-19T15:14:45.940 に答える