Performance 스키마와 sys 스키마 2

Performance 스키마와 sys 스키마에서 본 Performance 스키마(Performance Schema)는 인스트루먼트(instrument)가 잰 결과를 켜진 컨슈머(consumer)의 테이블에 쌓는다. 이 문서는 그 결과가 어떤 테이블에 어떤 모양으로 쌓이는지, 합계를 내 둔 요약 테이블을 어떻게 읽는지, 그리고 수집에 드는 메모리와 부담을 다룬다.

이벤트 테이블: 현재·최근·요약

Performance 스키마는 측정 결과 하나하나를 이벤트(event)라 부른다. 이벤트는 네 층으로 겹쳐 있다. 트랜잭션(transaction) 안에 문장(statement)이, 문장 안에 단계(stage)가, 단계 안에 대기(wait)가 들어 있다. 이 영어 이름이 뒤에 나오는 테이블 이름의 statements·stages·waits가 된다.

다이어그램 로딩…

각 이벤트는 자기를 감싼 상위 이벤트를 NESTING_EVENT_ID로 가리킨다. 그래서 "이 느린 문장이 어느 단계에서 무엇을 기다렸나"를 거슬러 따라갈 수 있다. 종류마다 테이블이 세 개씩 있다.

• events_statements_current: 스레드마다 지금 진행 중이거나 마지막 이벤트 한 건.
• events_statements_history: 스레드마다 끝난 최근 이벤트 몇 건(자동 설정으로 보통 10건).
• events_statements_history_long: 서버 전체에서 끝난 최근 이벤트(보통 1만 건).

statements 자리에 stages·waits·transactions를 넣으면 다른 층의 테이블이 된다.

요약 테이블: 다이제스트

실무에서 가장 많이 보는 것은 개별 이벤트가 아니라 합계를 내 둔 요약 테이블이다. 대표가 events_statements_summary_by_digest다. 다이제스트(digest)는 쿼리의 상수를 ?로 바꿔 모양만 남긴 문장이다. WHERE id = 1과 WHERE id = 2는 같은 다이제스트로 합쳐진다.

이 테이블은 다이제스트마다 실행 횟수(COUNT_STAR), 총 실행 시간(SUM_TIMER_WAIT), 검사한 행 수(SUM_ROWS_EXAMINED), 인덱스를 쓰지 않은 횟수(SUM_NO_INDEX_USED)를 쌓는다. 총 실행 시간이 큰 다이제스트부터 보면 서버 시간을 가장 많이 쓰는 쿼리 모양을 찾을 수 있고, 검사한 행 수가 유난히 많거나 인덱스를 쓰지 않은 횟수가 크면 인덱스를 손볼 후보다. 시간 단위는 피코초(1조분의 1초)라 그대로 읽기 어렵다. 그래서 보통은 이 값을 사람이 읽는 단위로 바꿔 주는 sys 스키마(sys schema)의 뷰(view)로 본다. 요약 테이블은 TRUNCATE TABLE로 비워 측정 구간을 새로 시작할 수 있다.

메모리와 오버헤드

Performance 스키마의 테이블은 메모리 버퍼다. MySQL 8.4는 버퍼 크기를 정하는 설정 대부분의 기본값을 -1(서버가 자동으로 정함)로 두고, 필요할 때 조금씩 늘린다. 한 번 잡은 메모리는 서버를 끌 때까지 반납하지 않고 재사용한다. 얼마나 쓰는지는 Performance 스키마 자신에게 물어본다. 아래 쿼리는 Performance 스키마가 스스로 잡은 메모리를 용도별로 나눠, 지금 쓰는 바이트 수(CURRENT_NUMBER_OF_BYTES_USED)를 보여 준다.

SELECT EVENT_NAME, CURRENT_NUMBER_OF_BYTES_USED
FROM performance_schema.memory_summary_global_by_event_name
WHERE EVENT_NAME LIKE 'memory/performance_schema/%';

오버헤드(overhead), 즉 측정 때문에 서버가 추가로 쓰는 CPU와 메모리는 매뉴얼 표현대로 "매우 적게" 설계되어 있다. 그래도 켜는 인스트루먼트와 컨슈머가 많을수록 수집할 일과 메모리가 늘어난다. 그래서 기본 설정은 그대로 두고, 기본으로 꺼져 있는 단계 측정 같은 것은 조사할 때만 켰다가 끈다. 켜고 끄는 방법은 setup_instruments에서 해당 인스트루먼트(단계라면 stage/%)의 ENABLED를, setup_consumers에서 해당 컨슈머(events_stages_%)의 ENABLED를 바꾸는 것이다.

이어지는 내용은 Performance 스키마와 sys 스키마 3에서 다룬다.

면접 포인트

• 계층: transaction → statement → stage → wait. 상위 이벤트는 NESTING_EVENT_ID로 거슬러 간다.
• 테이블은 current(스레드마다 지금 1건)·history(스레드마다 최근 몇 건)·history_long(서버 전체 최근)·summary(합계).
• events_statements_summary_by_digest: 상수를 지운 쿼리 모양별 실행 횟수·총 시간·검사 행 수. 시간은 피코초라 보통 sys 뷰로 본다.
• 메모리는 필요할 때 늘리고 반납하지 않는다. 기본 설정은 두고, 단계 측정 같은 것은 조사할 때만 켠다.