데이터베이스 응답, 느린 질의를 먼저 찾습니다

대기 시간을 질의·연결·자원으로 나눕니다

데이터베이스가 느릴 때 서버 크기를 먼저 올리는 것은 가장 비싼 선택입니다. 원인을 세 갈래로 나눠야 합니다. 첫째는 질의 자체가 느린 경우입니다. 색인이 없거나 조건이 넓어 많은 행을 읽습니다. 둘째는 연결이 부족한 경우입니다. 질의는 빠른데 연결을 기다리며 대기합니다. 셋째는 자원이 부족한 경우입니다. 메모리가 작아 디스크를 자주 읽습니다. 세 갈래는 지표로 구분됩니다. 질의별 실행 시간, 대기 중인 연결 수, 그리고 디스크 읽기 비율입니다. 이 세 지표를 같은 시간대에 겹쳐 보면 어느 갈래인지 바로 드러납니다.

상위 질의 몇 개가 대부분을 차지합니다

질의 쪽 문제라면 전체를 손볼 필요가 없습니다. 실행 시간의 합계가 큰 질의 상위 몇 개가 전체의 대부분을 차지하는 경우가 많습니다. 그래서 1단계로 질의를 실행 시간 합계로 정렬합니다. 호출 횟수가 많아 합계가 큰 질의와, 한 번이 매우 느려 합계가 큰 질의를 구분합니다. 조치가 다릅니다. 전자는 캐시나 호출 횟수 줄이기가 효과적이고, 후자는 색인 추가나 질의 재작성이 효과적입니다. 2단계로 상위 5개만 골라 하나씩 고칩니다. 3단계로 고친 뒤 다시 정렬해 순위가 바뀌었는지 확인합니다. 순위가 그대로면 조치가 듣지 않은 것입니다.

상위 질의 개선 효과를 계산합니다

학습용 가정으로 계산합니다. 가정값은 월 질의 실행 시간 합계가 40,000초이고 상위 5개가 그중 70퍼센트를 차지한다고 두겠습니다. 상위 5개의 합계는 28,000초입니다. 그중 가장 큰 질의가 2,000초였고 색인을 추가해 100초로 줄었다면 절감은 1,900초입니다. 상위 5개 합계는 26,100초로 내려갑니다. 이것이 중간 계산값입니다. 최종 판단은 사용자 체감으로 합니다. 합계가 줄었어도 느린 화면이 그대로면 그 화면의 질의가 상위에 없었던 것이므로, 화면별 응답 시간과 질의 목록을 연결해 다시 봐야 합니다.

색인을 늘리면 쓰기가 느려집니다

결론을 뒤집는 조건은 쓰기 부하입니다. 색인은 읽기를 빠르게 하지만 쓰기마다 갱신 비용이 생깁니다. 쓰기가 많은 표에 색인을 여러 개 추가하면 전체가 더 느려질 수 있습니다. 그래서 색인 추가 전에 그 표의 읽기와 쓰기 비율을 확인하고, 추가 뒤 쓰기 지연을 다시 측정합니다. 두 번째 조건은 연결 수입니다. 애플리케이션 대수를 늘리면 연결이 함께 늘어 데이터베이스 상한에 닿습니다. 이때는 질의를 고쳐도 개선되지 않으므로 연결을 모아 쓰는 계층이 필요합니다. 그래서 진단 문서에는 읽기 쓰기 비율과 현재 연결 수를 함께 적습니다.

성능 최적화 실행 전 점검표

• 질의 실행 시간·대기 연결 수·디스크 읽기 비율을 겹쳐 보았다
• 질의를 실행 시간 합계로 정렬해 상위 5개를 골랐다
• 호출이 많은 질의와 한 번이 느린 질의를 구분해 조치했다
• 색인 추가 뒤 쓰기 지연을 다시 측정했다