카산드라 읽기/쓰기 성능 - 높은 CPU

Question

나는 지난 며칠 동안 Casandra를 사용하기 시작했으며 여기에 내가하려는 일이 있습니다.

사용자 프로필을 유지하는 약 2 백만 개 이상의 개체가 있습니다. 나는이 객체들을 json으로 변환하고 압축하여 blob 컬럼에 저장한다. 평균 압축 json 크기는 약 10KB입니다. 내 표는 카산드라에서 보는 방법이있다

테이블 :

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

선택 쿼리 : 여기서 UID = ''dev.userprofile에서 선택 프로필;

업데이트 쿼리 :

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

매 시간마다, 나는 내 사용자 프로필 개체에 적용되는 큐에서 이벤트를 얻을. 각 이벤트는 하나의 userprofile 오브젝트에 해당합니다. 이러한 이벤트가 약 1 백만 가지가 발생하므로 짧은 시간 내에 1M 개의 userprofile 객체를 업데이트해야합니다. 즉, 응용 프로그램의 객체를 업데이트하고 json을 압축하고 cassandra blob을 업데이트해야합니다. 내가 선호하는 모든 1 백만 사용자 프로필 개체를 몇 분 안에 업데이트해야합니다. 그러나 나는 그것이 오래 걸리는 것을 알아 차린다.

내 응용 프로그램을 실행하는 동안 평균 약 400 개의 프로파일/초를 업데이트 할 수 있습니다. 나는 이미 CPU iowait를 많이 보았습니다 - 70 % +는 cassandra 인스턴스에 있습니다. 또한 부하는 처음에는 약 8 (vcpu 인스턴스 8)에서 약 16 정도로 매우 높아지고 약 4로 떨어집니다.

무엇이 잘못 되었나요? 왜냐하면 크기가 2KB 인 작은 개체를 업데이트 할 때마다 cassandra 작업/초가 훨씬 빠르다는 것을 알게되었습니다. 나는 대략 3000 Ops/sec를 얻을 수 있었다. 성능 향상 방법에 대한 의견이 있으십니까?

<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> 

난 그냥 테스트를 위해 m4.2xlarge의 AWS 인스턴스 내에서 카산드라 설정의 한 노드가

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

nodetool이 cfstats 출력

Keyspace: dev 
    Read Count: 688795 
    Read Latency: 27.280683695439137 ms. 
    Write Count: 688780 
    Write Latency: 0.010008401811899301 ms. 
    Pending Flushes: 0 
     Table: userprofile 
     SSTable count: 9 
     Space used (live): 32.16 GB 
     Space used (total): 32.16 GB 
     Space used by snapshots (total): 0 bytes 
     Off heap memory used (total): 13.56 MB 
     SSTable Compression Ratio: 0.9984539538554672 
     Number of keys (estimate): 2215817 
     Memtable cell count: 38686 
     Memtable data size: 105.72 MB 
     Memtable off heap memory used: 0 bytes 
     Memtable switch count: 6 
     Local read count: 688807 
     Local read latency: 29.879 ms 
     Local write count: 688790 
     Local write latency: 0.012 ms 
     Pending flushes: 0 
     Bloom filter false positives: 47 
     Bloom filter false ratio: 0.00003 
     Bloom filter space used: 7.5 MB 
     Bloom filter off heap memory used: 7.5 MB 
     Index summary off heap memory used: 2.07 MB 
     Compression metadata off heap memory used: 3.99 MB 
     Compacted partition minimum bytes: 216 bytes 
     Compacted partition maximum bytes: 370.14 KB 
     Compacted partition mean bytes: 5.82 KB 
     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.0 
     Maximum tombstones per slice (last five minutes): 1 

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

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 profiles/sec. 하지만 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의 덩어리로 나눠서 많은 압축을 얻지 못하는 오직 6 개의 값에 의해 지배 될 것입니다 (끔찍한 압축률 SSTable Compression Ratio: 0.9984539538554672으로 보여짐).

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

400 프로필/초는 매우 느리며 잠재적으로 병목 현상이 될 수있는 클라이언트에서 수행해야 할 작업이있을 수 있습니다. 8 코어 시스템에 4로드가 있다면 카산드라가 느려지지는 않을 것입니다. 요청을 병렬 처리하여 비동기 적으로 사용하여 순차적으로 요청을 보내는 것이 일반적인 문제입니다.

큰 BLOB가 있으면 GC에 영향을 미치므로이를 모니터링하고 그 정보를 추가하면 도움이 될 수 있습니다. 10kb 객체가 그다지 영향을 미치지는 않지만 그 객체는주의해야 할 점과 JVM 튜닝을 더 필요로 할 수도 있습니다.

도움이된다면, 힙 조정 및 3.0 또는 그 이상의 최신 버전으로의 업그레이드를 권장합니다.