높은 읽기 카산드라의 쓰기 대기 시간 2.2.6

Question

안녕 비슷한 질문은 이미 요청했지만, 난 우리가 조금 다른 문제가있는 것 같아요 :

우리는 카산드라는 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 

차이에 매우 유사한 구성되어 첫 번째는지도와 UDT를 많이 포함되어 있습니다. dev 센터에서의 간단한 테스트 * from ... limit 999; (Lucene 인덱스 등을 생략 함)는 첫 번째 인덱스의 경우 183ms이고 첫 번째 인덱스의 경우 1.8s입니다.

아무도 rootcause를 찾는 방법을 정의하는 데 도움이 될 수 있습니까? 조각 당

Answer 1

최대 살아있는 세포 (마지막 다섯 분) : 아마 당신의지도와 UDT의에서, 거대 182,785

. 데이터 모델이 근본 원인 일 가능성이 큽니다. 단일 쿼리를 만족시키기 위해 180k 셀을 걷는 것은 매우 느립니다.

select * from ... limit 999;

범위 쿼리가 본질적으로 느립니다. 단일 파티션에서 질문에 대답 할 수 있도록 테이블을 디자인하면 더 나은 결과를 얻을 수 있습니다.

당신이 나쁜 쿼리를하는 GC가있을 때마다

하나의 노드 설치

이 늘 사용하는 클라이언트 측 투기 경우 더 좋은 (나쁜 상처를 일시 정지합니다 같은 더 많은 노드를 추가하여을 완화 드라이버를 다시 시도하십시오).