Not enough admission control slots available for request
쿼리가 실행되지 않고 대기하거나 거부된다.
Impala 는 쿼리를 무제한으로 받지 않는다. 리소스 풀마다 동시 실행 쿼리 수, 대기열 길이, 메모리 상한을 두고 초과분을 대기시키거나 거부한다. 클러스터가 과부하로 무너지는 것을 막는 장치다.
여기서 말하는 슬롯은 코디네이터가 아니라 실행 노드(executor)당 동시 처리 단위다. Impala 3.4 이후 admission_control_slots 플래그로 노드당 슬롯 수를 정하며, 기본값은 노드의 CPU 코어 수에 맞춰 정해진다. 쿼리는 자신의 병렬도만큼 슬롯을 점유한다.
SHOW POOL_STATS;
출력에서 볼 항목은 다음과 같다.
| 항목 | 뜻 |
|---|---|
| Max Requests | 풀의 동시 실행 쿼리 상한 |
| Max Queued | 대기열 상한 |
| Max Memory | 풀 전체 메모리 상한 |
| Running / Queued | 현재 실행 · 대기 중 쿼리 수 |
웹 UI 에서도 본다. 코디네이터의 /admission 페이지에 풀별 상태와 최근 거부 사유가 나온다.
curl -s "http://impalad01:25000/admission" | head -50
먼저 진짜 부하인지 확인한다. 장시간 실행 중인 쿼리 하나가 슬롯을 붙들고 있는 경우가 많다.
SHOW QUERIES;
원인이 특정 쿼리라면 그 쿼리를 손본다. 파티션 가지치기가 되지 않아 전체 스캔하는 경우, 조인 순서가 나빠 중간 결과가 폭증하는 경우가 흔하다.
설정을 조정할 때는 Cloudera Manager 의 Dynamic Resource Pool 에서 풀별 Max Running Queries 와 Max Queued Queries, Max Memory 를 바꾼다. 노드당 슬롯 수 자체를 바꾸려면 impalad 의 --admission_control_slots 를 조정하고 재시작한다.
풀 지정 없이 실행돼 기본 풀에 몰리는 경우라면 세션에서 풀을 지정한다.
SET REQUEST_POOL=etl_pool;
동시 실행 수를 무작정 늘리면 메모리 압박으로 쿼리가 실패하거나 스필이 늘어 전체가 느려진다. 노드 수와 메모리, 쿼리 성격을 함께 본다. 짧은 대화형 쿼리 위주라면 동시 실행을 늘리고 쿼리당 메모리를 낮게, 무거운 배치라면 반대로 잡는다. 두 성격이 섞여 있으면 풀을 나누는 것이 정답이다.
변경 후에는 SHOW POOL_STATS 의 Queued 추이와 쿼리 실패율을 함께 본다. 대기가 줄었는데 메모리 부족 실패가 늘었다면 과하게 올린 것이다.