Kudu 가 어느 디스크를 쓰고 있고 테이블별로 얼마를 차지하는지 확인하는 방법을 정리한다.
데이터 디렉터리는 --fs_data_dirs, WAL 디렉터리는 --fs_wal_dir, 메타데이터 디렉터리는 --fs_metadata_dir 로 정해진다. Cloudera Manager 로 관리하는 클러스터는 설정 파일이 프로세스 디렉터리 밑에 생성되므로, 실행 중인 프로세스의 인자를 보는 편이 확실하다.
ps -ef | grep kudu-tserver
tr '\0' '\n' < /proc/$(pgrep -f kudu-tserver | head -1)/cmdline | grep fs_
웹 UI 에서도 볼 수 있다.
http://<tserver>:8050/config
kudu cluster ksck <master-addresses>
ksck 출력의 tablet server 요약에 서버별 태블릿 수와 on-disk 크기가 나온다. 서버 간 값이 크게 벌어져 있으면 리밸런스 대상이다.
웹 UI 에서는 tablet server 목록 페이지의 크기 항목을 본다.
http://<master>:8051/tablet-servers
http://<tserver>:8050/tablets
kudu table statistics <master-addresses> <table-name>
kudu table list <master-addresses>
table statistics 는 해당 테이블의 on-disk 크기와 라이브 row 수 추정을 돌려준다. 이 값은 복제본을 포함한 수치인지 아닌지가 버전에 따라 다르므로, ksck 의 서버별 합계와 비교해 해석한다. (확인 필요)
Impala 에서 보는 방법도 있다.
SHOW TABLE STATS db.tbl;
du -sh /var/lib/kudu/tserver/data
du -sh /var/lib/kudu/tserver/wals
df -h
Kudu 는 로그 블록 관리자(log block manager)를 써서 여러 블록을 소수의 컨테이너 파일에 담는다. 그래서 파일 수는 적고 파일 하나가 크게 보인다. du 값이 ksck 가 보고하는 논리 크기보다 큰 것은 삭제된 블록의 공간이 아직 회수되지 않았기 때문일 수 있다.
curl -s http://<tserver>:8050/metrics | grep -iE "on_disk_size|log_block_manager"
curl -s http://<tserver>:8050/jsonmetricz | head
Prometheus 로 수집할 때는 문자열 값을 갖는 메트릭이 섞여 있어 숫자 파싱이 실패할 수 있다. kudu_master_clock_ntp_status 처럼 상태 문자열을 돌려주는 항목이 대표적이므로, 수집기에서 해당 항목을 제외하거나 파싱 실패를 무시하도록 처리한다.
kudu fs 하위 명령은 로컬 파일시스템을 직접 여는 도구라 tablet server 가 떠 있는 동안 실행하면 안 된다.