많은 카산드라 및 OOM 관련 문제가 있음을 알고 있지만이 문제는 조금 다릅니다.카산드라 OOM 충돌
저희 회사는 베타 단계에서 Cassandra 3.9를 실행하는 제품에 대한 테스트 환경을 갖추고 있습니다. 이 환경은 4 개의 vCPU와 8GB의 RAM이있는 단일 노드에서 실행됩니다. 5 개월 동안이 환경에는 정기적 인 데이터가 제공되었으므로 하루에 약 40,000 개의 행이 단일 OOM없이 실행됩니다.
몇 주 전에 우리는 테스트 환경의 한계를보기 위해 더 많은 데이터를로드하기로 결정했고 약 500k 개의 행을 몇 시간 만에 삽입했습니다. 그 결과 카산드라는 OOM 때문에 추락했습니다. 그 후, 우리는 500k 행을 삭제하고 응용 프로그램을 다시 시작하여 매일 40k 행을 공급받습니다.
부하 테스트를 수행 한 후에 변경 사항을 되 돌렸지 만 주당 2 회처럼 OOM과 VM 충돌이 정기적으로 발생했습니다.
제 질문은, 왜 카산드라가 그런 행동을한다고 생각합니까? 그것은 어떻게 든 카산드라가 그 한계를 확장했고 예전보다 더 많은 메모리를 필요로하는 것 같습니다.
UPDATE
이 데이터 모델에 몇 테이블이 있지만,이 80 %로, 읽기 -90 % 그들의 주요 두 가지/쓰기 없습니다 :
CREATE TABLE global_events (
customer_id bigint,
start_dt timestamp,
client_id text,
connected boolean,
site_id bigint,
exit boolean,
is_new boolean,
is_visitor boolean,
last_seen timestamp,
PRIMARY KEY (customer_id, start_dt, client_id)
);
CREATE INDEX global_events_connected_idx ON global_events (connected);
CREATE INDEX global_events_site_id_idx ON global_events (site_id);
CREATE INDEX global_events_exit_idx ON global_events (exit);
CREATE INDEX global_events_is_new_idx ON global_events (is_new);
CREATE INDEX global_events_is_visitor_idx ON global_events (is_visitor);
CREATE TABLE local_events (
customer_id bigint,
local_id bigint,
start_dt timestamp,
client_id text,
connected boolean,
exit boolean,
is_new boolean,
is_visitor boolean,
last_seen timestamp,
PRIMARY KEY ((customer_id, local_id), start_dt, client_id)
);
CREATE INDEX local_events_connected_idx ON local_events (connected);
CREATE INDEX local_events_is_new_idx ON local_events (is_new);
CREATE INDEX local_events_is_visitor_idx ON local_events (is_visitor);
더를
있습니다 이 테이블의 TTL은 삭제 표시가 없으므로 쓰기가 많은 시스템입니다.
데이터 모델은 무엇입니까? 동일한 파티션에 계속 추가하면 색인 오버 헤드가 문제가 될 것입니다. –
cassandra.yaml 설정을 확인하여 캐시 설정에서 메모리 크런치가 발생하는지 확인하십시오. –
@ChrisLohfink 데이터 모델을 추가했습니다 – serdar