<@U0A71G31CDV> starrocks version 4.0.4 이고, k8s 환경...
# questions-and-troubleshooting
u
@Rocky starrocks version 4.0.4 이고, k8s 환경에 구성된 클러스터입니다 그런데, 클러스터 실행 후 아래와 같은 쿼리요청이 계속 생성되는데요 원인과 조치 방법에 대한 확인이 필요합니다 계속 요청되는 쿼리 select count(*) cnt from information_schema.tables
r
StarRocks 4.0.4 버전 및 Kubernetes(k8s) 환경에서
select 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`를 확인하여 해당 쿼리를 던지는 클라이언트의 정보를 찾습니다.
Copy code
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`(실행 간격) 값을 늘립니다.
Copy code
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
u
@Rocky starrocks ui 의 sessions 탭을 확인해 보니 “there are 65 active sessions”로 확인되고 요청 쿼리도 “SELECT COUNT(*) CNT FRom INFORMATION_SCHEMA TABLES” 도 확인 되는데 sessions 정보를 더 상세 하게 볼 수 있는 방법이나 sesseions 관리 하는 방법을 알려줘
r
StarRocks UI에서 확인되는 65개의 세션 정보와 해당 쿼리(
SELECT COUNT(*) FROM INFORMATION_SCHEMA.TABLES
)를 보다 상세히 분석하고 관리하는 방법을 안내해 드립니다. 1. 세션 정보 상세 조회 방법 UI보다 더 구체적인 정보를 얻으려면 SQL 인터페이스(MySQL 클라이언트 등)를 통해 다음 명령어를 사용하세요. * 전체 세션 목록 조회:
Copy code
sql
    SHOW FULL PROCESSLIST;
* Id: 세션의 고유 ID (강제 종료 시 사용) * User / Host: 어떤 계정으로, *어느 IP(Host)*에서 접속했는지 확인 가능합니다. (K8s 환경이라면 특정 Pod의 IP인지 확인하세요) * Time: 해당 세션이 현재 상태로 머문 시간(초)입니다. * Command: `Sleep`(유휴 상태)인지 `Query`(실행 중)인지 표시됩니다. * Info: 실행 중인 전체 SQL 문을 보여줍니다. * 조건별 필터링 (Information Schema 활용): 세션이 많을 경우 특정 조건으로 검색하면 편리합니다.
Copy code
sql
    SELECT * FROM information_schema.processlist
    WHERE command != 'Sleep'
    ORDER BY time DESC;
2. 세션 관리 및 강제 종료 불필요하게 점유된 세션이 있다면 직접 종료할 수 있습니다. * 특정 세션 종료: `SHOW PROCESSLIST`에서 확인한
Id
값을 사용하여 종료합니다.
Copy code
sql
    -- Id가 123인 세션 종료
    KILL 123;
3. 세션이 줄지 않고 쌓이는 이유와 해결책 65개의 세션이 계속 유지되는 이유는 StarRocks의 기본 유휴 세션 타임아웃(
wait_timeout
)
설정이 매우 길기 때문일 가능성이 큽니다. * 기본값 확인: StarRocks의 기본 `wait_timeout`은 *28,800초(8시간)*입니다. 즉, 클라이언트가 명시적으로 연결을 끊지 않으면 8시간 동안 세션이 유지됩니다. * 원인: K8s 환경의 Liveness/Readiness Probe가 쿼리를 던진 후 세션을 제대로 닫지 않거나, 커넥션 풀(Connection Pool) 설정이 과도하게 잡혀 있을 수 있습니다. 조치 방법: 타임아웃 단축 유휴 세션을 자동으로 정리하려면 시스템 변수를 조정하세요. (예: 1시간으로 변경)
Copy code
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
u
@Rocky command 가 sleep 이고 state 가 EOF 인 sesseions 정보는 뭐지?
r
`Command`가 *Sleep*이고 `State`가 *EOF*인 세션 상태는 *"클라이언트가 쿼리 수행을 마치고 연결은 유지한 채 다음 명령을 기다리고 있는 유휴(Idle) 상태"*를 의미합니다. 상세한 내용은 다음과 같습니다. 1. 용어의 의미 * Command: Sleep: 현재 이 세션(커넥션)이 아무런 작업을 하지 않고 쉬고 있다는 뜻입니다. 클라이언트가 `Close`를 호출하지 않고 연결을 열어두고 있는 상태입니다. * State: EOF (End of File): StarRocks(및 MySQL 프로토콜)에서 서버가 이전 쿼리의 결과를 클라이언트에게 모두 보냈음을 알리는 마지막 패킷을 보냈다는 뜻입니다. 즉, *"데이터 전송이 성공적으로 끝났음"*을 나타내는 상태값입니다. 2. 왜 65개나 쌓여 있나요? (원인 분석) 이 상태의 세션이 많다는 것은 *커넥션 풀(Connection Pool)*을 사용하는 도구나 *상태 확인(Health Check) 스크립트*가 연결을 맺은 뒤 제대로 닫지 않고 있기 때문입니다. * K8s Readiness/Liveness Probe: `mysql -e "SELECT..."`와 같은 명령어를 셸에서 실행하면 종료 시 자동으로 연결이 끊기지만, 특정 라이브러리나 스크립트에서 명시적으로 `QUIT`을 보내지 않으면 `wait_timeout`이 지날 때까지 이 상태로 남습니다. * StarRocks Operator: 클러스터 상태 감시를 위해 주기적으로 연결을 시도하며, 효율성을 위해 세션을 유지할 수 있습니다. * BI/모니터링 도구: Grafana나 DBeaver 같은 도구는 쿼리를 실행한 후 다음 쿼리를 빠르게 실행하기 위해 연결을 끊지 않고 유지합니다. 3. 문제가 되나요? * 리소스 소모:
Sleep
상태의 세션은 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