2017-12-21 6 views
1

こんにちは同様の質問は、すでに依頼されたが、私たちは少し異なる問題を抱えていると思います:ハイ読むカサンドラでの書き込みレイテンシは2.2.6

我々はカサンドラ2.2.6一つのノードのインストールを使用(および最新にアップグレードする予定)。今はクエリの時間がひどく、時にはタイムアウトを書きます。

Read Count: 21554802 
    Read Latency: 10.702975718589295 ms. 
    Write Count: 19437551 
    Write Latency: 27.806026818707767 ms. 
    Pending Flushes: 0 
      Table: ----- 
      SSTable count: 5 
      Space used (live): 661310370 
      Space used (total): 661310370 
      Space used by snapshots (total): 704698632 
      Off heap memory used (total): 845494 
      SSTable Compression Ratio: 0.13491738106721324 
      Number of keys (estimate): 179623 
      Memtable cell count: 594836 
      Memtable data size: 8816212 
      Memtable off heap memory used: 0 
      Memtable switch count: 3343 
      Local read count: 21554802 
      Local read latency: 11,744 ms 
      Local write count: 19437551 
      Local write latency: 30,506 ms 
      Pending flushes: 0 
      Bloom filter false positives: 387 
      Bloom filter false ratio: 0,00024 
      Bloom filter space used: 258368 
      Bloom filter off heap memory used: 258328 
      Index summary off heap memory used: 34830 
      Compression metadata off heap memory used: 552336 
      Compacted partition minimum bytes: 180 
      Compacted partition maximum bytes: 12108970 
      Compacted partition mean bytes: 23949 
      Average live cells per slice (last five minutes): 906.8858219156              92 
      Maximum live cells per slice (last five minutes): 182785 
      Average tombstones per slice (last five minutes): 1.2507830              9697 
      Maximum tombstones per slice (last five minutes): 50 

比較のために、10Mのレコードに関する含む別のテーブルがあると上記

Read Count: 815780599 
    Read Latency: 0.1672932019580917 ms. 
    Write Count: 3083462 
    Write Latency: 1.5470194706469547 ms. 
    Pending Flushes: 0 
      Table: ------ 
      SSTable count: 9 
      Space used (live): 5067447115 
      Space used (total): 5067447115 
      Space used by snapshots (total): 31810631860 
      Off heap memory used (total): 19603932 
      SSTable Compression Ratio: 0.2952622065160448 
      Number of keys (estimate): 12020796 
      Memtable cell count: 300611 
      Memtable data size: 18020553 
      Memtable off heap memory used: 0 
      Memtable switch count: 97 
      Local read count: 815780599 
      Local read latency: 0,184 ms 
      Local write count: 3083462 
      Local write latency: 1,692 ms 
      Pending flushes: 0 
      Bloom filter false positives: 7 
      Bloom filter false ratio: 0,00000 
      Bloom filter space used: 15103552 
      Bloom filter off heap memory used: 15103480 
      Index summary off heap memory used: 2631412 
      Compression metadata off heap memory used: 1869040 
      Compacted partition minimum bytes: 925 
      Compacted partition maximum bytes: 1916 
      Compacted partition mean bytes: 1438 
      Average live cells per slice (last five minutes): 1.0 
      Maximum live cells per slice (last five minutes): 1 
      Average tombstones per slice (last five minutes): 1.0193396020053622 
      Maximum tombstones per slice (last five minutes): 3 
と全く同様に構成

違いは、第1のマップおよびUDTの多くを含んでいます。デベロッパーセンターでのシンプルなテスト* from ... limit 999; (Luceneインデックスなどは省略しています)、最後のものは183ms、最初のものは1.8sです。

誰でも根本原因を見つける方法を定義できますか?スライスあたり

答えて

2

最大生細胞(最後の5分):182785

おそらくあなたのマップとのUDTから、巨大です。あなたのデータモデルは根本的な原因になりがちです。単一のクエリを満たすためにライブの180kセルを歩くことは非常に遅くなります。

select * from ... limit 999;

範囲クエリは本質的に遅いです。単一のパーティションから質問に答えることができるようにテーブルを設計してみると、より良い結果が得られます。

あなたが悪いクエリを持っていますGCがあるたびに

1は、ノードのインストール

が、これは文句を言わない使用のクライアント側投機的であればさらに良い(悪い傷つける一時停止が、このような複数のノードを追加することによって軽減されますドライバを再試行してください)。

+0

ありがとうございました。だから私の結果を2つの上記の表と比較すると、あなたが提案した最初の答えにつながると思います。しかし、これは生のレコードサイズ、特にUDTやマップの使用に関係しますか?今のところこのように考えると、実際には1つの列があり、大きなリストを含み、もはや使用されず、廃止されたデータはまだクリアされています。クリアして再度チェックしようとします。 – Slavomir

+0

私はあなたのファンです:)問題の70%は20分で解決されます。 :)(巨大なリストを含むコラムを削除しました) – Slavomir

+0

この場合、Cassandra 3.xにアップグレードすることでパフォーマンスをさらに向上させることは可能ですか? – Slavomir

関連する問題