쿼리 성능 가이드라인
이 문서는 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초
| 자세한 내용은 Metrics Instrumentation 문서를 참조하세요. |
- 쿼리의 성능을 분석할 때 캐시의 찬/온도 여부에 주의하십시오. 이러한 가이드라인은 모든 캐시 유형에 적용됩니다.
- 배치 쿼리를 처리할 때 범위와 배치 크기를 변경하여 쿼리 타이밍 및 캐싱에 어떤 영향을 미치는지 확인하세요.
- 기존 쿼리의 성능이 좋지 않으면 개선하는 데 노력하십시오. 너무 복잡하거나 개발을 지연시킬 경우 즉시 대응할 수 있도록 후속 조치를 취하세요. 데이터베이스 리뷰어나 유지관리자에게 도움과 지침을 요청할 수 있습니다.
찬/온도 캐시
쿼리 성능을 평가할 때 찬/온도 캐시된 쿼리 사이의 차이를 이해하는 것이 중요합니다.
쿼리를 처음 실행하면 “찬 캐시”에서 실행됩니다. 즉, 디스크에서 읽어야 합니다. 쿼리를 다시 실행하면 데이터를 캐시 또는 PostgreSQL이 공유 버퍼라고 부르는 것에서 읽을 수 있습니다. 이것이 “온도 캐시” 쿼리입니다.
EXPLAIN 계획을 분석할 때, Buffers 출력을 보면 시간뿐만 아니라 EXPLAIN(analyze, buffers)로 실행하여 Buffers 출력을 확인하여 차이를 볼 수 있습니다. Database Lab은 이러한 옵션을 자동으로 포함합니다.
온도 캐시 쿼리를 실행하면 shared hits만 볼 수 있습니다.
예를 들어 Database Lab을 사용하면 다음과 같습니다:
Shared buffers:
- hits: 36467 (~284.90 MiB) from the buffer pool
- reads: 0 from the OS file cache, including disk I/O
또는 psql의 계획에서:
Buffers: shared hit=7323
캐시가 찬 경우에는 reads도 볼 수 있습니다.
Database Lab을 사용하면 다음과 같습니다:
Shared buffers:
- hits: 17204 (~134.40 MiB) from the buffer pool
- reads: 15229 (~119.00 MiB) from the OS file cache, including disk I/O
psql에서는 다음과 같습니다:
Buffers: shared hit=7202 read=121
도움말