Impala 에서 Kudu 테이블을 읽다가 3분 즈음에 실패한다.
Unable to open scanner for node with id '0' for Kudu table 'db.tbl':
Timed out: exceeded configured scan timeout of 180s: ScanRequest RPC to 10.0.0.21:7050 timed out
같은 시각 tserver 로그에는 다음이 남는다.
RowProjector compilation request submit failed: Service unavailable: thread pool is at capacity
(1/1 tasks running, 100/100 tasks queued) [suppressed 190 similar messages]
[suppressed N similar messages] 의 N 은 같은 메시지가 그만큼 더 발생했으나 로그 폭주를 막기 위해 생략됐다는 뜻이다. 심각도를 가늠하는 숫자로 읽으면 된다.
Kudu 클라이언트가 아니라 Impala 쪽 기본값이다. impalad 의 Kudu 연산 타임아웃이 3분(180000ms)으로 설정돼 있어 그 값이 그대로 메시지에 찍힌다. Kudu 의 스캐너 TTL(--scanner_ttl_ms, 기본 60초)과는 다른 값이다.
즉 이 오류는 "Kudu 가 3분 안에 응답하지 못했다"는 사실만 말한다. 타임아웃을 늘리는 것은 증상 완화이지 해결이 아니다.
RowProjector 는 스캔할 때 필요한 컬럼만 뽑아내는 코드를 실행 시점에 생성하는 부품이다. 이 생성 작업을 처리하는 스레드 풀이 포화됐다는 것은, 서로 다른 형태의 스캔 요청이 짧은 시간에 대량으로 몰렸다는 뜻이다. 생성 결과는 캐시되므로, 같은 형태의 스캔이 반복되면 캐시 적중으로 부담이 사라진다.
몰리는 전형적인 상황은 세 가지다. 동시 실행 쿼리가 많고 각각 다른 컬럼 조합을 읽는 경우, mt_dop 를 올려 노드 안의 스캔 스레드가 늘어난 경우, 그리고 tserver 가 이미 CPU · 메모리 압박을 받고 있어 모든 작업이 밀리는 경우다.
큐가 막히면 연결도 함께 무너져 recv error: network error · shutting down server connection 이 뒤따른다.
먼저 부하를 줄인다. Impala 쪽에서 동시 실행 수를 낮추고(admission control), mt_dop 를 기본값으로 되돌리고, 전체 컬럼을 읽는 습관적인 SELECT * 를 줄인다. 같은 컬럼 조합을 쓰는 쿼리끼리 묶이면 코드 생성 캐시 적중률이 올라간다.
tserver 자원 상태를 확인한다. :8050/metrics 와 CM 차트에서 CPU · 메모리 · 디스크 대기를 본다. 스캔이 느린 진짜 원인이 디스크인 경우가 많다.
그래도 타임아웃이 필요하다면 impalad 의 Kudu 연산 타임아웃을 올린다. Cloudera Manager 의 Impala Daemon 안전 밸브에 넣는다.
--kudu_operation_timeout_ms=300000
Kudu 쪽 스레드 풀·큐 관련 플래그는 버전마다 이름이 달라 그대로 옮겨 쓰면 기동이 실패한다. 적용 전에 해당 버전에서 유효한 플래그인지 확인한다.
kudu-tserver --helpmatch=codegen
직접 설치한 환경이면 설정 파일에 한 줄씩 적는다.
--scanner_ttl_ms=300000
sudo systemctl restart kudu-tserver
Cloudera Manager 환경에서는 파일을 직접 고치지 않는다. CM 이 기동 때마다 설정을 다시 생성하므로 변경이 사라진다. Kudu 서비스의 gflagfile 안전 밸브에 넣는다.