쿼리 성능 가이드라인

이 문서는 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 출력을 보면 타이밍 뿐만 아니라 shared hits를 살펴봄으로써 이 차이를 확인할 수 있습니다. Database Lab은 이러한 옵션을 자동으로 포함합니다.

웜 캐시 쿼리를 실행할 때, shared hits만 볼 수 있습니다.

예를 들어, Database Lab의 사용:

공유 버퍼:
  - hits: 버퍼 풀에서 36467개(~284.90 MiB)
  - OS 파일 캐시에서 0개의 읽기, 디스크 I/O 포함

또는 psql의 계획에서:

Buffers: shared hit=7323

캐시가 콜드 상태인 경우, reads도 볼 수 있습니다.

Database Lab을 사용한 경우:

공유 버퍼:
  - hits: 버퍼 풀에서 17204개(~134.40 MiB)
  - OS 파일 캐시에서 15229개(~119.00 MiB)의 읽기, 디스크 I/O 포함

psql에서:

Buffers: shared hit=7202 read=121