GitLab 패키지의 번들 Puma 인스턴스 구성

Puma 메모리 사용량 튜닝, 워커 타임아웃 변경, SSL 설정, Unicorn에서 Puma로 전환, 트러블슈팅 방법을 설명합니다.

Puma는 Ruby 애플리케이션을 위한 빠른 멀티스레드 고동시성 HTTP 1.1 서버입니다. GitLab의 사용자 기능을 제공하는 핵심 Rails 애플리케이션을 실행합니다. 메모리 사용량 튜닝 # 메모리 사용량을 줄이기 위해 Puma는 워커 프로세스를 포크합니다. 워커가 생성될 때마다 기본 프로세스와 메모리를 공유합니다. 워커는 메모리 페이지를 변경하거나 추가할 때만 추가 메모리를 사용합니다. 이로 인해 Puma 워커는 추가 웹 요청을 처리하면서 시간이 지남에 따라 더 많은 물리 메모리를 사용하게 될 수 있습니다. 시간이 지남에 따라 사용되는 메모리의 양은 GitLab 사용 방식에 따라 다릅니다. GitLab 사용자가 더 많은 기능을 사용할수록 시간이 지남에 따라 더 높은 메모리 사용량이 예상됩니다. 통제되지 않은 메모리 증가를 막기 위해 GitLab Rails 애플리케이션은 감시 스레드를 실행하여, 워커가 일정 시간 동안 지정된 상주 세트 크기(RSS) 임계값을 초과하면 자동으로 워커를 재시작합니다. GitLab은 메모리 제한의 기본값으로 1500Mb 를 설정합니다. 기본값을 재정의하려면 per_worker_max_memory_mb 를 새 RSS 제한값(메가바이트)으로 설정하세요: /etc/gitlab/gitlab.rb 를 편집합니다: puma[ 'per_worker_max_memory_mb' ] = 1200 # 1.2 GB GitLab을 재구성합니다: sudo gitlab-ctl reconfigure 워커가 재시작되면 짧은 시간 동안 GitLab 실행 용량이 줄어듭니다. 워커가 너무 자주 교체된다면 per_worker_max_memory_mb 를 더 높은 값으로 설정하세요. 워커 수는 CPU 코어 수를 기준으로 계산됩니다. 4~8개의 워커가 있는 소규모 GitLab 배포는 워커가 너무 자주 재시작되는 경우(분당 1회 이상) 성능 문제가 발생할 수 있습니다. 서버에 여유 메모리가 있는 경우 per_worker_max_memory_mb 값을 높이는 것이 도움이 될 수 있습니다. 데이터베이스 연결 계획 # Puma 워커나 스레드를 늘리기 전에 PostgreSQL max_connections 설정에 미치는 데이터베이스 연결 영향을 고려하세요. 자세한 연결 계획 및 계산 방법은 PostgreSQL 튜닝 페이지를 참조하세요. 워커 재시작 모니터링 # GitLab은 워커가 높은 메모리 사용량으로 인해 재시작되는 경우 로그 이벤트를 내보냅니다. 다음은 /var/log/gitlab/gitlab-rails/application_json.log 에서 이러한 로그 이벤트 중 하나의 예시입니다: { "severity" : "WARN" , "time" : "2023-01-04T09:45:16.173Z" , "correlation_id" : null , "pid" : 2725 , "worker_id" : "puma_0" , "memwd_handler_class" : "Gitlab::Memory::Watchdog::PumaHandler" , "memwd_slee