양명구
09/18/2026, 1:17 AMRocky
09/18/2026, 1:18 AMselect count(*) cnt from information_schema.tables 쿼리가 지속적으로 발생하는 현상은 주로 *클러스터의 상태 확인(Health Check) 또는 모니터링 도구*에 의해 발생합니다.
원인 분석과 조치 방법은 다음과 같습니다.
1. 주요 원인
1. Kubernetes Liveness/Readiness Probe (가장 가능성 높음):
* StarRocks를 Helm 차트나 Operator로 배포했을 때, FE(Frontend) 포드의 상태를 확인하기 위해 mysql 클라이언트를 이용한 SQL 실행을 Probe로 설정하는 경우가 많습니다.
* 특히 포트 체크(TCP)만으로 부족할 때, 실제로 SQL 처리가 가능한지 확인하기 위해 위와 같은 가벼운 쿼리를 주기적으로 던집니다.
2. StarRocks Operator의 상태 동기화(Reconciliation):
* StarRocks Operator는 클러스터의 상태를 유지하기 위해 FE가 정상적으로 작동하는지 지속적으로 확인합니다. 이 과정에서 특정 사용자(주로 `root`나 operator)로 접속하여 쿼리를 수행할 수 있습니다.
3. 모니터링 및 BI 도구의 Heartbeat:
* Grafana, DBeaver, Prometheus SQL Exporter 등 외부 도구가 연결되어 있는 경우, 세션 유지를 위해 주기적으로 'Keep-alive' 쿼리를 보냅니다.
* `information_schema.tables`는 권한 문제가 적고 DB 상태를 확인하기 가장 표준적인 테이블이라 자주 사용됩니다.
2. 원인 확인 방법 (진단)
가장 먼저 쿼리의 *발생지(IP)*와 *사용자(User)*를 확인해야 합니다.
* Audit Log 확인:
FE의 `fe.audit.log`를 확인하여 해당 쿼리를 던지는 클라이언트의 정보를 찾습니다.
sql
-- 감사 로그가 테이블로 로드되어 있다면 SQL로 확인 가능
SELECT user, clientIp, queryText
FROM starrocks_audit_db*.starrocks_audit_tbl*
WHERE queryText LIKE '%information_schema.tables%'
ORDER BY timestamp DESC LIMIT 10;
* `clientIp`가 `127.0.0.1`이나 FE 포드 자신의 IP라면 *K8s Probe*일 가능성이 큽니다.
* `clientIp`가 Operator 포드의 IP라면 *Operator의 상태 체크*입니다.
3. 조치 방법
상황 A: Kubernetes Probe인 경우 (정상 동작)
이는 클러스터의 고가용성을 유지하기 위한 정상적인 동작입니다. 만약 쿼리 빈도가 너무 잦아 부하가 걱정된다면 K8s Manifest의 설정을 조정하세요.
* 조치: StarRocksCluster 커스텀 리소스(CRD)나 Helm `values.yaml`에서 readinessProbe 또는 `livenessProbe`의 `periodSeconds`(실행 간격) 값을 늘립니다.
yaml
readinessProbe:
periodSeconds: 30 # 기본값(보통 5~10초)에서 늘림
상황 B: 외부 모니터링/BI 도구인 경우
* 조치: 연결된 외부 도구(Grafana, DBeaver 등)의 설정에서 "Keep-Alive" 또는 "Validation Query" 설정을 끄거나 주기를 변경합니다.
상황 C: 쿼리 로그가 너무 많이 쌓여 불편한 경우
쿼리 자체가 시스템에 주는 부하는 매우 미미하지만, `fe.audit.log`가 지저분해지는 것이 문제라면 감사 로그 필터링을 고려할 수 있습니다.
* 참고: StarRocks는 기본적으로 모든 쿼리를 기록합니다. 특정 쿼리를 로그에서 제외하는 설정은 공식적으로 제공되지 않으므로, 로그 로테이션 정책을 강화하거나 로그 분석 시 해당 패턴을 제외하고 보는 것이 일반적입니다.
요약: 해당 쿼리는 시스템이 *"SQL을 실행할 준비가 되었는가?"*를 묻는 가장 안전한 방법입니다. `fe.audit.log`에서 `clientIp`를 확인하여 K8s 내부 인프라(Probe/Operator)에서 오는 것인지 먼저 확인하시기 바랍니다.
References
• sql-reference/information_schema/tables.md
• administration/management/monitoring/metrics.md
• quick_start/helm.md
• sql-reference/sql-statements/cluster-management/tablet_replica/SHOW_TABLE_STATUS.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md
• sql-reference/information_schema/information_schema.md양명구
09/21/2026, 1:06 AMRocky
09/21/2026, 1:07 AMSELECT COUNT(*) FROM INFORMATION_SCHEMA.TABLES)를 보다 상세히 분석하고 관리하는 방법을 안내해 드립니다.
1. 세션 정보 상세 조회 방법
UI보다 더 구체적인 정보를 얻으려면 SQL 인터페이스(MySQL 클라이언트 등)를 통해 다음 명령어를 사용하세요.
* 전체 세션 목록 조회:
sql
SHOW FULL PROCESSLIST;
* Id: 세션의 고유 ID (강제 종료 시 사용)
* User / Host: 어떤 계정으로, *어느 IP(Host)*에서 접속했는지 확인 가능합니다. (K8s 환경이라면 특정 Pod의 IP인지 확인하세요)
* Time: 해당 세션이 현재 상태로 머문 시간(초)입니다.
* Command: `Sleep`(유휴 상태)인지 `Query`(실행 중)인지 표시됩니다.
* Info: 실행 중인 전체 SQL 문을 보여줍니다.
* 조건별 필터링 (Information Schema 활용):
세션이 많을 경우 특정 조건으로 검색하면 편리합니다.
sql
SELECT * FROM information_schema.processlist
WHERE command != 'Sleep'
ORDER BY time DESC;
2. 세션 관리 및 강제 종료
불필요하게 점유된 세션이 있다면 직접 종료할 수 있습니다.
* 특정 세션 종료:
`SHOW PROCESSLIST`에서 확인한 Id 값을 사용하여 종료합니다.
sql
-- Id가 123인 세션 종료
KILL 123;
3. 세션이 줄지 않고 쌓이는 이유와 해결책
65개의 세션이 계속 유지되는 이유는 StarRocks의 기본 유휴 세션 타임아웃(wait_timeout) 설정이 매우 길기 때문일 가능성이 큽니다.
* 기본값 확인:
StarRocks의 기본 `wait_timeout`은 *28,800초(8시간)*입니다. 즉, 클라이언트가 명시적으로 연결을 끊지 않으면 8시간 동안 세션이 유지됩니다.
* 원인: K8s 환경의 Liveness/Readiness Probe가 쿼리를 던진 후 세션을 제대로 닫지 않거나, 커넥션 풀(Connection Pool) 설정이 과도하게 잡혀 있을 수 있습니다.
조치 방법: 타임아웃 단축
유휴 세션을 자동으로 정리하려면 시스템 변수를 조정하세요. (예: 1시간으로 변경)
sql
-- 전역 설정 (이후 접속되는 세션에 적용)
SET GLOBAL wait_timeout = 3600;
-- 현재 세션에만 적용
SET wait_timeout = 3600;
4. 권장 확인 사항
* Host IP 확인: `SHOW PROCESSLIST`의 Host 컬럼에 나타나는 IP가 K8s Node IP인지, 혹은 특정 Pod(예: StarRocks Operator)의 IP인지 확인하십시오.
* Probe 설정: 만약 K8s Probe가 원인이라면, mysql 커맨드를 직접 실행하는 방식 대신 http 기반의 상태 확인(StarRocks FE 8030 포트)으로 변경하는 것이 세션 관리에 더 유리할 수 있습니다.
References
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROCESSLIST.md
• administration/management/resource_management/Query_management.md
• sql-reference/System_variable.md
• faq/operation_maintenance_faq.md
References
• sql-reference/System_variable.md
• faq/operation_maintenance_faq.md
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROCESSLIST.md
• administration/management/resource_management/Query_management.md양명구
09/21/2026, 1:12 AMRocky
09/21/2026, 1:12 AMSleep 상태의 세션은 CPU를 사용하지 않으며 메모리 소모도 매우 적습니다. 다만, FE(Frontend)의 최대 연결 수(max_connections, 기본값 보통 1024)를 점유하므로 너무 많아지면(수천 개 이상) 새로운 접속이 차단될 수 있습니다.
* 해결책: 이전 답변에서 언급한 것처럼 wait_timeout 값을 조정하여 너무 오래된 유휴 세션은 서버가 자동으로 끊도록 설정하는 것이 가장 일반적인 관리 방법입니다.
4. 확인 팁
`SHOW FULL PROCESSLIST`를 실행했을 때 Time 컬럼을 확인해 보세요.
* `Time`이 매우 큰 숫자로 올라가고 있다면: 클라이언트가 연결을 재사용하지 않고 버려둔 세션입니다.
_ `Time`이 수 초 내외로 계속 리셋된다면: 해당 세션이 주기적으로 위에서 본 COUNT(_) 쿼리를 실행하며 살아있는 상태(Keep-alive)입니다.
요약하자면, Sleep / EOF 상태는 "직전에 시킨 일은 완벽히 끝냈고, 지금은 다음 지시를 기다리며 대기 중"인 지극히 정상적인 상태입니다. 다만 그 수가 너무 많다면 커넥션을 생성하는 주체(K8s Probe 또는 앱)가 세션을 재사용하거나 잘 닫고 있는지 점검이 필요합니다.
References
• sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROCESSLIST.md
• sql-reference/System_variable.md
• administration/management/resource_management/Query_management.md
• administration/management/monitoring/metrics.md
• metrics)
• sql-reference/information_schema/information_schema.md
• sql-reference/sql-statements/cluster-management/nodes_processes/KILL.md
• /KILL)
• faq/operation_maintenance_faq.md
• administration/management/monitoring/Audit_log.md