tablet server 메모리를 나누는 주요 플래그와, 이 값들을 어떤 신호를 보고 조정하는지 정리한다.
| 플래그 | 기본값 | 의미 |
|---|---|---|
--memory_limit_hard_bytes |
0 (무제한) | tablet server 프로세스 메모리 상한. 이 값의 일정 비율을 넘으면 쓰기를 거부한다 |
--block_cache_capacity_mb |
512 | 디스크에서 읽은 블록을 담는 캐시 크기 |
--tablet_transaction_memory_limit_mb |
64 | 태블릿 하나가 커밋되지 않은 쓰기 연산에 쓸 수 있는 메모리 |
--rpc_max_message_size |
50MiB | 단일 RPC 메시지 최대 크기 |
Cloudera Manager 에서는 같은 값이 "Block Cache Capacity" · "Tablet Transaction Memory Limit" 같은 이름으로 노출된다.
block cache 는 데이터 블록뿐 아니라 기본 키 인덱스와 블룸 필터 블록도 담는다. 그래서 반복 조회뿐 아니라 UPSERT · UPDATE · DELETE 처럼 PK 존재 여부를 먼저 확인하는 연산의 지연에도 영향을 준다.
기본값은 512MB 이고, 이 값은 물리 메모리에 비례해 자동 계산되지 않는다. 대용량 노드에서 그대로 두면 캐시가 사실상 작동하지 않는 상태가 되므로, 조회 비중이 큰 클러스터에서는 명시적으로 올린다. 다만 이 메모리는 --memory_limit_hard_bytes 안에서 함께 계산되므로, 캐시를 키우면 쓰기에 쓸 메모리가 그만큼 줄어든다.
효과를 판단하려면 히트율을 본다.
curl -s http://<tserver>:8050/metrics | grep -i block_cache
block_cache_hits_caching 과 block_cache_misses_caching 비율로 히트율을 계산한다. 90% 아래면 부족을 의심하고, 95% 이상이면 더 늘려도 얻을 것이 없다. 대량 INSERT 만 도는 워크로드에서는 캐시를 키워도 이득이 없다. 쓰기 경로(MemRowSet → flush → WAL)는 캐시를 거치지 않기 때문이다.
캐시 용량이 메모리 한도 대비 과도하면 Kudu 가 기동을 거부한다. 그 경우 --force_block_cache_capacity 로 우회할 수 있으나, 이는 의도적으로 안전장치를 끄는 조작이므로 한도 자체를 재검토하는 편이 옳다.
--tablet_transaction_memory_limit_mb 는 태블릿 단위 한도다. tablet server 에 태블릿이 많으면 이론상 합계는 태블릿 수만큼 커질 수 있으나, 실제로는 프로세스 전체 한도(--memory_limit_hard_bytes)가 먼저 걸린다.
이 값이 --rpc_max_message_size 보다 작으면 기동 시 다음 경고가 나온다.
--tablet_transaction_memory_limit_mb is set too low compared with --rpc_max_message_size
큰 RPC 하나가 태블릿 한도를 넘겨 버리면 그 쓰기는 항상 실패하게 되므로, 두 값의 관계를 맞춰야 한다는 경고다. 대량 배치 적재에서 한 번에 보내는 행 수가 많다면 --tablet_transaction_memory_limit_mb 를 올리거나 클라이언트 쪽 배치 크기를 줄인다.
flush 와 compaction 은 maintenance 스레드가 수행한다.
curl -s http://<tserver>:8050/maintenance-manager
실행 중 작업이 항상 스레드 수만큼 차 있고 대기 큐가 줄지 않으면 --maintenance_manager_num_threads 를 데이터 디스크 수에 맞춰 올린다. 기본값은 1이라 디스크가 여러 장인 노드에서는 거의 항상 부족하다.
kudu tserver get_flags 출력에서 확인한다.