カッサンドラ読み込み/書き込みパフォーマンス - 高CPU

Question

私はここ数日からCasandraを使い始めました。ここで私がやろうとしていることがあります。

私は、ユーザーのプロファイルを維持する約200万件のオブジェクトを持っています。これらのオブジェクトをjsonに変換し、圧縮してブロブの列に格納します。圧縮された平均jsonサイズは約10KBです。

dev.userprofile (uid varchar primary key, profile blob); 

選択クエリ：これは私のテーブルには、カサンドラに見え、

表方法です 'UID =' dev.userprofileからプロファイルを選択します。

更新クエリ：

update dev.userprofile set profile='<bytebuffer>' where uid = '<uid>' 

時間ごとに、私はUSERPROFILEオブジェクトに適用されたキューからイベントを取得します。各イベントは1つのuserprofileオブジェクトに対応します。そのようなイベントは約1百万件ありますので、短時間で1Mのuserprofileオブジェクトを更新する必要があります。つまり、アプリケーション内のオブジェクトを更新し、jsonを圧縮して、cassandra blobを更新する必要があります。私は100万人のユーザープロファイルオブジェクトのすべてを数分で更新することをお勧めします。しかし、私は今それが長くかかることに気付きます。

私のアプリケーションを実行している間に、平均で約400プロファイル/秒を更新できることがわかりました。私はすでにCPU iowaitをたくさん見ています - 70％+はcassandraインスタンスです。また、負荷は最初は約8（vcpuのインスタンスで8）になり、約4に下がりました。

私は間違っていますか？なぜなら、サイズが2KBの小さなオブジェクトを更新するとき、私はcassandra操作/秒がはるかに高速であることに気付きました。私は約3000OPS /秒​​を得ることができました。どのようにパフォーマンスを改善する必要がありますか？

<dependency> 
    <groupId>com.datastax.cassandra</groupId> 
    <artifactId>cassandra-driver-core</artifactId> 
    <version>3.1.0</version> 
</dependency> 
<dependency> 
    <groupId>com.datastax.cassandra</groupId> 
    <artifactId>cassandra-driver-extras</artifactId> 
    <version>3.1.0</version> 
</dependency> 

私はちょうど

Single node Cassandra instance 
m4.2xlarge aws ec2 
500 GB General Purpose (SSD) 
IOPS - 1500/10000 

nodetool cfstats出力

​​

nodetool出力

Percentile SSTables  Write Latency  Read Latency Partition Size  Cell Count 
           (micros)   (micros)   (bytes) 
50%    3.00    9.89   2816.16    4768     2 
75%    3.00    11.86   43388.63    8239     2 
95%    4.00    14.24   129557.75    14237     2 
98%    4.00    20.50   155469.30    17084     2 
99%    4.00    29.52   186563.16    20501     2 
Min    0.00    1.92    61.22    216     2 
Max    5.00   74975.55  4139110.98   379022     2 

をcfhistogramsを試験するためm4.2xlargeのAWSインスタンス内Cassandraのセットアップの一つのノードを有します

DSTAT出力

---load-avg--- --io/total- ---procs--- ------memory-usage----- ---paging-- -dsk/total- ---system-- ----total-cpu-usage---- -net/total- 
1m 5m 15m | read writ|run blk new| used buff cach free| in out | read writ| int csw |usr sys idl wai hiq siq| recv send 
12.8 13.9 10.6|1460 31.1 |1.0 14 0.2|9.98G 892k 21.2G 234M| 0  0 | 119M 3291k| 63k 68k| 1 1 26 72 0 0|3366k 3338k 
13.2 14.0 10.7|1458 28.4 |1.1 13 1.5|9.97G 884k 21.2G 226M| 0  0 | 119M 3278k| 61k 68k| 2 1 28 69 0 0|3396k 3349k 
12.7 13.8 10.7|1477 27.6 |0.9 11 1.1|9.97G 884k 21.2G 237M| 0  0 | 119M 3321k| 69k 72k| 2 1 31 65 0 0|3653k 3605k 
12.0 13.7 10.7|1474 27.4 |1.1 8.7 0.3|9.96G 888k 21.2G 236M| 0  0 | 119M 3287k| 71k 75k| 2 1 36 61 0 0|3807k 3768k 
11.8 13.6 10.7|1492 53.7 |1.6 12 1.2|9.95G 884k 21.2G 228M| 0  0 | 119M 6574k| 73k 75k| 2 2 32 65 0 0|3888k 3829k 

編集

がsstables上LeveledCompactionStrategy &無効の圧縮に切り替え、私は大きな改善が見ていない：

プロファイルの改善のビットがありました/秒が更新されました。現在は550-600プロファイル/秒です。しかし、CPUスパイク、すなわちiowaitが残っています。

gcstats

Interval (ms) Max GC Elapsed (ms)Total GC Elapsed (ms)Stdev GC Elapsed (ms) GC Reclaimed (MB)   Collections  Direct Memory Bytes 
      755960     83    3449     8   73179796264     107      -1 

dstats

---load-avg--- --io/total- ---procs--- ------memory-usage----- ---paging-- -dsk/total- ---system-- ----total-cpu-usage---- -net/total- 
1m 5m 15m | read writ|run blk new| used buff cach free| in out | read writ| int csw |usr sys idl wai hiq siq| recv send 
7.02 8.34 7.33| 220 16.6 |0.0 0 1.1|10.0G 756k 21.2G 246M| 0  0 | 13M 1862k| 11k 13k| 1 0 94 5 0 0| 0  0 
6.18 8.12 7.27|2674 29.7 |1.2 1.5 1.9|10.0G 760k 21.2G 210M| 0  0 | 119M 3275k| 69k 70k| 3 2 83 12 0 0|3906k 3894k 
5.89 8.00 7.24|2455 314 |0.6 5.7 0|10.0G 760k 21.2G 225M| 0  0 | 111M 39M| 68k 69k| 3 2 51 44 0 0|3555k 3528k 
5.21 7.78 7.18|2864 27.2 |2.6 3.2 1.4|10.0G 756k 21.2G 266M| 0  0 | 127M 3284k| 80k 76k| 3 2 57 38 0 0|4247k 4224k 
4.80 7.61 7.13|2485 288 |0.1 12 1.4|10.0G 756k 21.2G 235M| 0  0 | 113M 36M| 73k 73k| 2 2 36 59 0 0|3664k 3646k 
5.00 7.55 7.12|2576 30.5 |1.0 4.6 0|10.0G 760k 21.2G 239M| 0  0 | 125M 3297k| 71k 70k| 2 1 53 43 0 0|3884k 3849k 
5.64 7.64 7.15|1873 174 |0.9 13 1.6|10.0G 752k 21.2G 237M| 0  0 | 119M 21M| 62k 66k| 3 1 27 69 0 0|3107k 3081k 

あなたは、CPUスパイクに気づくことができました。私はさらに負荷が増大する前に

私の主な関心事は、iowaitのです。何か私はこれを引き起こしているものを探している必要がありますか？ 600プロファイル/秒（つまり、600読み込み+書き込み）が私には低いようです。

Answer 1

LeveledCompactionStrategyを試すことができますか？このような大きなオブジェクトに対する1：1の読み込み/書き込みでは、読み込み時に保存されたIOは、おそらくより高価な圧縮で費やされたIOに対抗します。

送信前にデータを圧縮している場合は、テーブルの圧縮をオフにする必要があります。 64kbのチャンクに分割すると、かなりの圧縮率（恐ろしい圧縮率SSTable Compression Ratio: 0.9984539538554672のように）が得られない6つの値だけが大きく左右されます。

ALTER TABLE dev.userprofile 
    WITH compaction = { 'class' : 'LeveledCompactionStrategy' } 
    AND compression = { 'sstable_compression' : '' }; 

400プロファイル/秒はしかし非常に非常に低速であり、潜在的にもボトルネックになる可能性があり、あなたのクライアント上で行うにはいくつかの仕事があるかもしれません。 8コアシステムに4つの負荷がある場合、カッサンドラが遅くなることはありません。要求を並列化して非同期で使用し、要求を順次送信することが共通の問題であることを確認してください。

blobが大きいほど、GCに影響が出るため、それらを監視して情報を追加すると役立ちます。私は10kbのオブジェクトがそれに多大な影響を与えることに驚いていますが、それを目にするものは多くあり、JVMのチューニングをもっと必要とするかもしれません。

これが役立つ場合は、ヒープをチューニングして3.0以上のバージョンにアップグレードすることをおすすめします。