쿼리 성능 가이드라인
이 문서는 SQL 쿼리를 최적화할 때 따를 수 있는 다양한 가이드라인을 설명합니다.
SQL 쿼리를 최적화할 때 주의해야 할 두 가지 요소가 있습니다.
- 쿼리 실행 시간. 이것은 사용자가 GitLab을 어떻게 경험하는지를 반영하는 중요한 요소입니다.
- 쿼리 계획. 쿼리 계획을 최적화하는 것은 쿼리가 독립적으로 시간이 지남에 따라 확장될 수 있도록 하는 데 중요합니다. 색인이 쿼리를 점점 느리게 만들기 전에 테이블이 커지면 쿼리가 잘 수행되도록 유지하는 이유를 분석하는 것이 왜 중요한지의 한 예입니다.
쿼리에 대한 시간 가이드라인
| 쿼리 유형 | 최대 쿼리 시간 | 참고사항 |
|---|---|---|
| 일반 쿼리 | 100ms
| 이것은 강제 제한은 아니지만, 쿼리가 이 값을 초과하는 경우 최적화 여부를 이해하는 데 시간을 투자하는 것이 중요합니다. |
| 마이그레이션에서의 쿼리 | 100ms
| 게시된 마이그레이션 시간과는 다릅니다. |
| 마이그레이션 중의 동시 작업 | 5분
| 동시 작업은 데이터베이스를 차단하지 않지만 GitLab 업데이트를 차단합니다. add_concurrent_index 및 add_concurrent_foreign_key와 같은 작업을 포함합니다.
|
| 마이그레이션 후의 동시 작업 | 20분
| 동시 작업은 데이터베이스를 차단하지 않지만 GitLab 업데이트 프로세스를 차단합니다. add_concurrent_index 및 add_concurrent_foreign_key와 같은 작업을 포함합니다. 인덱스 생성이 20분을 초과하는 경우 비동기 인덱스 생성을 고려하세요.
|
| 백그라운드 마이그레이션 | 1초
| |
| 서비스 핑 | 1초
| 자세한 내용은 메트릭 계측 문서를 참조하세요. |
- 쿼리 성능을 분석할 때 캐시가 냉장 및 온열 캐시에 따라 보이는 지 여부에 주목하세요. 이러한 가이드라인은 두 유형의 캐시에 모두 적용됩니다.
- 일괄 처리 쿼리를 처리할 때 범위와 일괄 크기를 변경하여 쿼리 소요 시간과 캐싱에 어떤 영향을 미치는지 확인하세요.
- 기존 쿼리의 성능이 좋지 않은 경우 개선하기 위해 노력하세요. 너무 복잡하거나 개발을 멈출 수 있는 경우, 적시에 해결될 수 있도록 후속 조치를 취하세요. 언제든지 데이터베이스 리뷰어 또는 유지보수자에게 도움과 지침을 요청할 수 있습니다.
냉장 및 온열 캐시
쿼리 성능을 평가할 때 냉장 및 온열 캐시의 차이를 이해하는 것이 중요합니다.
쿼리를 처음 실행할 때 “냉장 캐시”에서 실행됩니다. 이는 디스크에서 읽어야 함을 의미합니다. 쿼리를 다시 실행하면 데이터는 캐시에서 또는 PostgreSQL에서 공유 버퍼라고 하는 것에서 읽을 수 있습니다. 이것이 “온열 캐시” 쿼리입니다.
EXPLAIN 계획을 분석할 때, Buffers 출력을 확인하는 것으로 타이밍뿐만 아니라 차이점을 볼 수 있습니다. EXPLAIN(analyze, buffers)로 실행하여 Buffers에 대한 출력을 확인할 수 있습니다. Database Lab은 이러한 옵션을 자동으로 포함합니다.
온열 캐시 쿼리를 하는 경우, shared hits만 보입니다.
예를 들어, Database Lab을 사용하면:
공유 버퍼:
- hits: 버퍼 풀에서 36467개 (~284.90 MiB)
- reads: 디스크 I/O를 포함한 OS 파일 캐시에서 0개
또는 psql에서 실행한 설명 계획에서는:
Buffers: shared hit=7323
캐시가 냉장인 경우, reads도 볼 수 있습니다.
Database Lab의 사용하기:
공유 버퍼:
- hits: 버퍼 풀에서 17204개 (~134.40 MiB)
- reads: 디스크 I/O를 포함한 OS 파일 캐시에서 15229개 (~119.00 MiB)
psql에서는:
Buffers: shared hit=7202 read=121
도움말