GitLab Performance Monitoring을 사용하면 성능 병목이 사용자에게 영향을 주기 전에 감지할 수 있습니다. 응답이 느려지거나 메모리 문제가 발생하면 SQL 쿼리, Ruby 처리, 시스템 리소스에 대한 상세 메트릭으로 정확한 원인을 짚어낼 수 있습니다.

성능 모니터링을 도입한 관리자는 문제가 인스턴스 전체로 번지기 전에 잠재적 문제를 즉시 알림으로 받습니다. 트랜잭션 시간, 쿼리 실행 성능, 메모리 사용량을 추적해 조직에 맞는 GitLab 성능을 유지합니다.

GitLab Performance Monitoring 구성 방법은 다음 문서를 참고합니다.

• Prometheus 문서.
• Grafana 구성.
• Performance bar.

수집되는 메트릭은 두 가지입니다.

1. 트랜잭션별 메트릭.
2. 샘플링 메트릭.

트랜잭션 메트릭#

트랜잭션 메트릭은 개별 트랜잭션과 연결할 수 있는 메트릭입니다. 트랜잭션 소요 시간, 실행된 SQL 쿼리의 소요 시간, HAML 뷰 렌더링에 걸린 시간 같은 통계가 여기 해당합니다. 이 메트릭은 처리되는 모든 Rack 요청과 Sidekiq job에 대해 수집됩니다.

샘플링 메트릭#

샘플링 메트릭은 개별 트랜잭션과 연결할 수 없는 메트릭입니다. 가비지 컬렉션 통계나 유지되는 Ruby 객체 수가 여기 해당합니다. 이 메트릭은 일정한 간격으로 수집되며, 이 간격은 두 가지 요소로 구성됩니다.

1. 사용자가 정의한 간격.
2. 그 간격에 더해지는 무작위 오프셋. 같은 오프셋이 연속해서 두 번 사용되지는 않습니다.

실제 간격은 정의된 간격의 절반부터 정의된 간격에 그 절반을 더한 값 사이가 됩니다. 예를 들어 사용자가 정의한 간격이 15초라면 실제 간격은 7.5초에서 22.5초 사이입니다. 이 간격은 한 번 생성해 프로세스가 살아 있는 동안 재사용하는 것이 아니라, 샘플링을 실행할 때마다 다시 생성됩니다.

사용자 정의 간격은 환경 변수로 지정할 수 있습니다. 인식되는 환경 변수는 다음과 같습니다.

• RUBY_SAMPLER_INTERVAL_SECONDS
• DATABASE_SAMPLER_INTERVAL_SECONDS
• ACTION_CABLE_SAMPLER_INTERVAL_SECONDS
• PUMA_SAMPLER_INTERVAL_SECONDS
• THREADS_SAMPLER_INTERVAL_SECONDS
• GLOBAL_SEARCH_SAMPLER_INTERVAL_SECONDS
• PG_ASH_SAMPLER_INTERVAL_SECONDS

활성 세션 기록#

활성 세션 기록(Active session history)은 기본 데이터베이스의 pg_stat_activity를 샘플링하므로, 과거 특정 시점에 데이터베이스가 무엇을 하고 있었는지 확인할 수 있습니다. GitLab은 샘플을 수집하고 저장하기 위해 pg_ash를 포함해 배포합니다.

이 기능은 실험 기능이며 프로덕션 사용에는 아직 적합하지 않습니다. 먼저 프로덕션이 아닌 환경에서 테스트합니다.

pg_ash는 기본적으로 설치되어 있지 않으며 샘플링도 기본적으로 꺼져 있습니다.

sudo gitlab-rake gitlab:db:pg_ash:install

sudo gitlab-rake gitlab:db:pg_ash:status

sudo gitlab-rake gitlab:db:pg_ash:uninstall

kubectl exec -it <toolbox-pod-name> -- gitlab-rake gitlab:db:pg_ash:install

kubectl exec -it <toolbox-pod-name> -- gitlab-rake gitlab:db:pg_ash:status

kubectl exec -it <toolbox-pod-name> -- gitlab-rake gitlab:db:pg_ash:uninstall

sudo docker exec -t <container-name> gitlab-rake gitlab:db:pg_ash:install

sudo docker exec -t <container-name> gitlab-rake gitlab:db:pg_ash:status

sudo docker exec -t <container-name> gitlab-rake gitlab:db:pg_ash:uninstall

sudo -u git -H bundle exec rake gitlab:db:pg_ash:install RAILS_ENV=production

sudo -u git -H bundle exec rake gitlab:db:pg_ash:status RAILS_ENV=production

sudo -u git -H bundle exec rake gitlab:db:pg_ash:uninstall RAILS_ENV=production

샘플링을 켜려면:

1. 관리자 액세스 권한이 있는 사용자로 로그인합니다.
2. 오른쪽 상단에서 Admin을 선택합니다.
3. 왼쪽 사이드바에서 Settings > Metrics and profiling을 선택합니다.
4. Active session history 섹션을 확장합니다.
5. Turn on session sampling 체크박스를 선택합니다.
6. 선택 사항. **Sample interval (seconds)**를 변경합니다. 기본값은 1초입니다.
7. Save changes를 선택합니다.

Sidekiq 프로세스의 백그라운드 스레드가 샘플을 수집합니다. 한 번에 하나의 프로세스만 샘플링하므로, 설정한 간격이 인스턴스 전체의 간격입니다. 샘플링에는 기본적으로 켜져 있는 GitLab Prometheus 메트릭 엔드포인트가 필요합니다. Sidekiq이 중지되면 샘플링도 중지되므로 재시작이나 배포 중에 샘플이 유실될 수 있습니다.

두 설정 중 어느 쪽을 변경하든 재시작 없이 적용되지만 즉시 적용되지는 않습니다. 각 Sidekiq 프로세스는 새 값을 최대 90초 안에 읽습니다.

PG_ASH_SAMPLER_INTERVAL_SECONDS는 Sidekiq 프로세스가 샘플링 프로세스를 넘겨받아야 하는지 확인하는 빈도를 설정합니다. 샘플 간격을 설정하지는 않습니다.

롤업 및 보존#

샘플링이 켜져 있는 동안 Sidekiq 크론 잡이 오래된 샘플을 요약하고 제거합니다.

시간은 크론 잡 시간대를 따르며 기본값은 UTC입니다.

pg_ash 기본값에서는 원시 샘플을 하루 전체와 당일 동안, 분 단위 행을 30일 동안, 시간 단위 행을 5년 동안 보관합니다. 보존 값은 ash.config 테이블에 있습니다. 이를 위한 관리자 설정은 이슈 608100에서 제안되었습니다.

원시 샘플은 요약된 후에만 제거됩니다. 로테이션이 이를 확인하지 못하면 로테이션이 실패하고 gitlab_pg_ash_consecutive_rotate_failures 메트릭이 증가합니다. gitlab:db:pg_ash:status Rake 작업도 같은 카운터를 보여 줍니다.

샘플링을 끄면 잡이 중지됩니다. 그때까지 수집된 데이터는 pg_ash를 제거할 때까지 남아 있습니다.