3장. Context · 스레드 · 동시성

하나의 서버 프로세스 안에서 쿼리·머지·백업이 뒤엉키지 않는 이유 — 설정 6단계 머지, 스레드 풀 계층, CPU slot이라는 교통정리 시스템을 해부합니다.

3.1 Context 계층 — 이 설정은 대체 어디서 온 걸까

ClickHouse의 모든 동작은 설정(settings)으로 제어됩니다. 문제는 설정의 출처가 한 곳이 아니라는 것 — 코드 기본값부터 쿼리의 SETTINGS 절까지 6단계가 겹겹이 쌓이고, 뒤 단계가 앞 단계를 오버라이드합니다.

<!-- 잘못된 시도: 세션 설정은 백그라운드 머지에 영향 없음 -->
-- SET max_bytes_to_merge_at_max_space_in_pool = ...  ❌

<!-- 올바른 방법: users.xml의 background 프로파일에 추가 ✅ -->
<profiles>
    <background>
        <max_bytes_to_merge_at_max_space_in_pool>161061273600</max_bytes_to_merge_at_max_space_in_pool>
    </background>
</profiles>
<!-- 프로파일명은 background_profile 서버 설정으로 변경 가능 -->

3.2 스레드 풀 계층 — 스레드를 빌려 쓰는 조직도

스레드 생성·소멸은 비싼 작업이므로, ClickHouse는 스레드 풀 체계를 씁니다. 모든 특수 풀은 최상위 싱글톤인 Global Thread Pool 위에 세워진 계층 구조입니다. 특수 풀의 역할은 스레드를 직접 만드는 게 아니라 동시 작업 수 제한과 스케줄링입니다.

3.3 쿼리 하나 = 스레드 여러 개 — ThreadGroup의 구조

어느 풀에서 스레드를 받든, 작업 시작 시 ThreadStatus 인스턴스가 생성됩니다. Thread ID, Query ID, 성능 카운터, 리소스 소비량을 캡슐화한 객체로, thread-local 포인터라 CurrentThread::get()으로 어디서든 접근합니다. 그렇다면 쿼리 하나를 여러 스레드가 나눠 처리할 때, 이들은 어떻게 하나로 묶일까요?

3.4 ConcurrencyControl — CPU slot으로 하는 좌석 배정

max_threads의 기본값은 쿼리 하나가 모든 코어를 쓰도록 되어 있습니다. 그런데 그런 쿼리가 10개 동시에 실행되면? 스레드가 코어 수의 10배가 되어 컨텍스트 스위칭·캐시 미스·메모리 오버헤드가 폭증합니다. ConcurrencyControl은 CPU slot이라는 좌석제를 도입해 이 문제를 풉니다.

• 스레드를 실행하려면 먼저 slot을 획득(acquire)해야 하고, 끝나면 반환(release)합니다.
• 서버 전체 slot 수는 concurrent_threads_soft_limit_num으로 전역 제한됩니다.
• 각 slot은 free → granted → acquired → (release) → free의 상태 머신입니다.

// 1단계: 최소 1개 ~ 최대 max_threads개 slot 요청
//        첫 slot은 즉시 부여 — 이것이 "soft limit"의 핵심
auto slots = ConcurrencyControl::instance().allocate(1, max_threads);

// 2단계: slot이 부여될 때마다 스레드 생성
while (auto slot = slots->tryAcquire())
    spawnThread([slot = std::move(slot)] { ... });

// 3단계: 전체 slot 수는 재시작 없이 런타임 조정 가능
ConcurrencyControl::setMaxConcurrency(concurrent_threads_soft_limit_num);

3.5 종합 — SELECT 쿼리 하나의 라이프사이클

1. 커넥션 수락 → Server pool에서 Master thread 할당
2. Context 구성 → Global → Profile → User → Session → Query 순서로 설정 머지
3. 파싱·해석 → Parser → AST → Interpreter → QueryPipeline (2장)
4. slot 할당 → allocate(1, max_threads), 최소 1개 즉시 확보
5. 스레드 실행 → ThreadGroup 생성, Worker들이 attach하여 MemoryTracker·ProfileEvents 집계
6. Pipeline 실행 → Processor DAG가 Block 단위로 필터·집계 처리
7. 결과 출력 → Format → WriteBuffer → 클라이언트
8. 정리 → slot 반환·재분배, system.query_log 기록

3.6 모니터링 — 스레드와 동시성 들여다보기

-- 현재 활성 스레드 현황
SELECT metric, value FROM system.metrics
WHERE metric IN ('GlobalThread', 'GlobalThreadActive',
                 'IOThreads', 'IOThreadsActive',
                 'BackgroundMergesAndMutationsPoolTask');

-- ConcurrencyControl 영향 확인: 요청한 스레드 vs 실제 사용한 스레드
SELECT query_id,
       Settings['max_threads']  AS requested_threads,
       length(thread_ids)       AS actual_threads,
       peak_memory_usage
FROM system.query_log
WHERE type = 'QueryFinish'
ORDER BY event_time DESC
LIMIT 20;

✍️ 이해도 체크