SET QUERY_TIMEOUT_S=3600 을 걸어 두었는데도 17시간째 끝나지 않는 쿼리가 남아 있다. 옵션이 동작하지 않는 것처럼 보인다.
이름 때문에 실행 시간 제한으로 오해하기 쉽지만, QUERY_TIMEOUT_S 는 쿼리가 아무 일도 하지 않은 채로 있었던 시간을 잰다. 쿼리가 계속 진행 중이거나 클라이언트가 결과를 계속 가져가는 동안에는 타이머가 늘지 않는다. impalad 플래그 --idle_query_timeout 의 설명에도 "The query option QUERY_TIMEOUT_S overrides this setting" 이라고 적혀 있어, 두 값이 같은 성격임을 알 수 있다.
실행 시간 자체를 제한하는 옵션은 따로 있다.
| 이름 | 성격 | 적용 |
|---|---|---|
QUERY_TIMEOUT_S |
유휴 시간 제한 | 세션 쿼리 옵션. --idle_query_timeout 의 세션별 재정의 |
EXEC_TIME_LIMIT_S |
실행 시간 제한 | 세션 쿼리 옵션. 지정 시간을 넘겨 실행 중이면 취소 |
--idle_query_timeout |
유휴 시간 제한 | impalad 기동 플래그. 세션 값의 상한 역할 |
--idle_session_timeout |
세션 유휴 제한 | impalad 기동 플래그. 세션 자체를 정리 |
장시간 실행 쿼리를 끊으려면 EXEC_TIME_LIMIT_S 를 쓴다.
SET EXEC_TIME_LIMIT_S=3600;
SET QUERY_TIMEOUT_S=600;
세션 옵션은 그 세션에만 걸린다. Hue · JDBC · BI 도구로 들어오는 쿼리에는 적용되지 않으므로, 전체에 강제하려면 리소스 풀의 기본 쿼리 옵션으로 넣는다. Cloudera Manager 에서는 동적 리소스 풀 설정의 "Default Query Options" 에 지정한다.
EXEC_TIME_LIMIT_S=3600,QUERY_TIMEOUT_S=600
취소 신호를 보냈는데도 쿼리가 목록에서 사라지지 않는 일이 있다. Impala 웹 UI 의 쿼리 상세에서 Execution cancelled 이후 Request finished 까지의 시간이 길게 잡혀 있으면, 실행이 계속된 것이 아니라 취소 후 정리가 끝나지 않은 상태다.
백엔드 fragment 가 Kudu 스캔 RPC 나 디스크 I/O 에서 멈춰 있으면 취소 신호를 확인하는 지점까지 도달하지 못한다. 이 상태는 유휴로도 분류되지 않아 유휴 타임아웃이 걸리지 않고, kudu_operation_timeout_ms 같은 클라이언트 기한도 그 코드 경로가 실행되지 않으므로 발동하지 않는다.
SELECT * FROM sys.impala_query_live WHERE state != 'FINISHED';
확인 순서는 다음과 같다. 해당 쿼리가 붙어 있던 tablet server 나 DataNode 의 상태를 보고, D 상태로 멈춘 프로세스나 디스크 오류가 있는지 확인한다. 노드가 회복되거나 프로세스가 재시작되어야 정리가 끝나는 경우가 많다.
ps -eo state,pid,cmd | awk '$1 ~ /D/'
dmesg -T | tail -50
EXEC_TIME_LIMIT_S 로 취소된 쿼리는 이미 쓴 데이터를 되돌리지 않는다. INSERT 계열에는 신중히 적용한다.