14

Cassandra を使用して画像を保存しています。現在、古いシステムから写真を大量に移行しています。しばらくの間はすべてがうまく機能しますが、最終的にはTimedOutException、作業キューがいっぱいになったためと思われる保存時にエラーが発生します。

しかし、それが完了するまで（数時間）待った後、状況は同じままです（移行を停止した後、それ自体は回復しません）。

tpstatsコマンドが次のデータを表示する1 つのノードのみに問題があるようです。

Cassandra tpstats

数時間前に挿入を停止したにもかかわらず、保留中の MutationStage 操作が増加し続けています。

それは正確にはどういう意味ですか？ミューテーションステージとは？

長い間安定していない理由を確認するには、何を確認できますか? リング内の他のすべてのサーバーの保留中の操作は 0 です。

新しい挿入を試みるとTimedOutException... 例外がスローされます。

これは役に立つ場合のリング情報です

ここに画像の説明を入力
(問題のあるノードは最初のものです)

EDIT：ログの最後の行は次のとおりです

INFO [OptionalTasks:1] 2013-02-05 10:12:59,140 MeteredFlusher.java (line 62) flushing high-traffic column family CFS(Keyspace='pics_persistent', ColumnFamily='master') (estimated 92972117 bytes)  
INFO [OptionalTasks:1] 2013-02-05 10:12:59,141 ColumnFamilyStore.java (line 643) Enqueuing flush of Memtable-master@916497516(74377694/92972117 serialized/live bytes, 141 ops)
INFO [OptionalTasks:1] 2013-02-05 10:14:49,205 MeteredFlusher.java (line 62) flushing high-traffic column family CFS(Keyspace='pics_persistent', ColumnFamily='master') (estimated 80689206 bytes)
INFO [OptionalTasks:1] 2013-02-05 10:14:49,207 ColumnFamilyStore.java (line 643) Enqueuing flush of Memtable-master@800272493(64551365/80689206 serialized/live bytes, 113 ops)
WARN [MemoryMeter:1] 2013-02-05 10:16:10,662 Memtable.java (line 197) setting live ratio to minimum of 1.0 instead of 0.0015255633589225548
INFO [MemoryMeter:1] 2013-02-05 10:16:10,663 Memtable.java (line 213) CFS(Keyspace='pics_persistent', ColumnFamily='master') liveRatio is 1.0 (just-counted was 1.0).  calculation took 38ms for 86 columns
INFO [OptionalTasks:1] 2013-02-05 10:16:33,267 MeteredFlusher.java (line 62) flushing high-traffic column family CFS(Keyspace='pics_persistent', ColumnFamily='master') (estimated 71029403 bytes)
INFO [OptionalTasks:1] 2013-02-05 10:16:33,269 ColumnFamilyStore.java (line 643) Enqueuing flush of Memtable-master@143498560(56823523/71029403 serialized/live bytes, 108 ops)
INFO [ScheduledTasks:1] 2013-02-05 11:36:27,798 GCInspector.java (line 122) GC for ParNew: 243 ms for 1 collections, 1917768456 used; max is 3107979264
INFO [ScheduledTasks:1] 2013-02-05 13:00:54,090 GCInspector.java (line 122) GC for ParNew: 327 ms for 1 collections, 1966976760 used; max is 3107979264
4

1 に答える 1

4

ノードの 1 つを書き込みで過負荷にしているだけだと思います。つまり、消化できるよりも速く書き込みます。書き込みが大きい場合、これは非常に簡単です。

クラスターへの書き込みを停止した後でも、MutationStage は増加しています。これは、他のノードがまだキューに入れられたミューテーション リクエストを処理しており、この過負荷のノードにレプリカを送信しているためです。

いくつかの理由が考えられるため、ノードの 1 つが過負荷になる理由はわかりません。

  • ノードが他のノードより遅い (異なるハードウェアまたは異なる構成)
  • クラスターのバランスが適切に取れていません (ただし、nodetool リング出力の最初の部分は、そうではないことを示唆しています)
  • ラウンドロビンなどにより、すべてのノードに均等に書き込みを分散するのではなく、すべての書き込みをこの特定のノードに向けています。
  • memtables の合計サイズ制限が大きすぎる/またはキャッシュ サイズが小さすぎるため、ノードが GC に苦労しており、たまたまこれが GC の死のスパイラルに陥った最初のノードでした
于 2013-09-20T14:02:54.703 に答える