어플라이언스의 일반적인 리소스 할당 문제 해결
Note
CI(연속 통합) 시스템, 빌드 서버 또는 기타 클라이언트(예: Git 또는 API 클라이언트)에서 GitHub Enterprise Server 인스턴스에 대한 반복 요청(폴링)을 정기적으로 수행하면 시스템에 과부하가 발생할 수 있습니다. 이로 인해 DoS(서비스 거부) 공격이 발생하여 상당한 성능 문제 및 리소스 포화가 발생할 수 있습니다.
이러한 문제를 방지하려면 웹후크를 사용하여 업데이트를 받는 것이 좋습니다. 웹후크를 사용하면 시스템에서 업데이트를 자동으로 푸시할 수 있으므로 일정한 폴링이 필요하지 않습니다. 또한 조건부 요청 및 캐싱 전략을 사용하여 불필요한 요청을 최소화하는 것이 좋습니다. 대규모 동시 일괄 처리(천둥 무리)에서 작업을 실행하지 않고 대신 웹후크 이벤트가 작업을 트리거할 때까지 기다립니다.
자세한 내용은 웹후크 정보을(를) 참조하세요.
모니터 대시보드를 사용하여 어플라이언스의 리소스 상태를 파악하고 이 페이지에 설명된 것과 같이 사용량이 많은 문제를 해결하는 방법에 대한 결정을 내리는 것이 좋습니다.
시스템 중요 문제 및 어플라이언스를 수정하기 전에 GitHub Enterprise 지원을(를) 방문하여 지원 번들을 포함하여 문의하는 것이 좋습니다. 자세한 내용은 “GitHub Enterprise 지원에 데이터 제공”을 참조하세요.
높은 CPU 사용량
가능성 있는 원인
- 인스턴스의 CPU가 워크로드에 대해 과소 프로비저닝됩니다.
- 새 GitHub Enterprise Server 릴리스로 업그레이드하면 새 기능으로 인해 CPU 및 메모리 사용량이 증가하는 경우가 많습니다. 또한 업그레이드 후 마이그레이션 또는 조정 백그라운드 작업은 완료될 때까지 일시적으로 성능이 저하될 수 있습니다.
- Git 또는 API에 대한 상승된 요청입니다. 과도한 리포지토리 복제, CI/CD 프로세스 또는 API 스크립트 또는 새로운 워크로드의 의도하지 않은 사용과 같은 다양한 요인으로 인해 Git 또는 API에 대한 요청이 증가할 수 있습니다.
- GitHub Actions 작업의 수가 증가했습니다.
- Git 명령의 증가로 인해 대규모 리포지토리가 실행되었습니다.
권장 사항
- CPU 코어가 적절하게 프로비전되었는지 확인합니다.
- 경고 임계값을 설정합니다.
- 업그레이드 후
ghe-check-background-upgrade-jobs를 실행하여 백그라운드 업그레이드 작업이 완료되었는지 확인합니다. - 끌어오기 대신 웹후크를 사용합니다.
- API 트래픽률 제한을 사용합니다.
- 현재 작업 및 Git 트래픽을 확인하여 Git 사용량을 분석합니다.
높은 메모리 사용량
가능한 원인
- 인스턴스의 메모리가 프로비저닝되지 않았습니다.
- Git 또는 API에 대한 상승된 요청입니다. 과도한 리포지토리 복제, CI/CD 프로세스 또는 API 스크립트 또는 새로운 워크로드의 의도하지 않은 사용과 같은 다양한 요인으로 인해 Git 또는 API에 대한 요청이 증가할 수 있습니다.
- 개별 서비스가 예상 메모리 사용량을 초과하고 OOM(메모리 부족)을 초과합니다.
- 백그라운드 작업 처리가 증가했습니다.
권장 사항
- 시간이 지남에 따라 사용량이 최소 권장 요구 사항을 초과할 수 있으므로 인스턴스의 메모리가 워크로드, 데이터 볼륨에 대해 부족하게 프로비전됩니다.
- Nomad 그래프 내에서 메모리 부족 추세가 있는 서비스를 식별합니다. 이 경우 다시 시작한 후 사용 가능한 메모리 추세가 자주 발생합니다. 자세한 내용은 모니터 대시보드에 대한 정보을(를) 참조하세요.
rg -z 'kernel: Out of memory: Killed process' /var/log/syslog*를 실행하여 메모리가 부족한 프로세스에 대한 로그를 확인합니다(이를 위해 먼저 SSH를 사용하여 관리 셸에 로그인합니다 - 관리 셸(SSH)에 액세스 참조).- CPU 서비스에 대한 메모리의 올바른 비율이 충족되는지 확인합니다(최소
6.5:1). - 백그라운드 처리를 위해 대기 중인 작업의 양을 확인합니다. 모니터 대시보드에 대한 정보을(를) 참조하세요.
낮은 디스크 공간 가용성
루트 파일 시스템 경로(/)에 마운트된 스토리지 볼륨과 사용자 파일 시스템 경로(/data/user)에 마운트된 스토리지 볼륨 모두 디스크 공간이 부족하면 인스턴스의 안정성에 문제가 발생할 수 있습니다.
루트 스토리지 볼륨은 동일한 크기의 두 파티션으로 분할된다는 점을 기억하세요. 파티션 중 하나가 루트 파일 시스템(/)으로 탑재됩니다. 다른 파티션은 필요한 경우 더 쉽게 롤백할 수 있도록 /mnt/업그레이드로 업그레이드 및 업그레이드 롤백 시에만 마운트됩니다. 자세한 내용은 시스템 개요을(를) 참조하세요.
가능성 있는 원인
- 서비스 오류로 인해 로그 양이 증가
- 유기 트래픽을 통한 높은 디스크 사용량
권장 사항
- 실행(
sudo du -csh /var/log/*)을 통해/var/log폴더의 디스크 사용량을 확인하거나 수동으로 로그 회전을 강제 실행(sudo logrotate -f /etc/logrotate.conf)합니다. - 디스크에서 삭제되었지만 여전히 열린 파일 핸들(
ghe-check-disk-usage)이 있는 대용량 파일을 확인합니다. - 디스크 스토리지 용량을 늘려 보세요. 스토리지 용량 늘리기을(를) 참조하세요.
평소보다 높은 응답 시간
가능한 원인
- Git 또는 API에 대한 상승된 요청입니다. 과도한 리포지토리 복제, CI/CD 프로세스 또는 API 스크립트 또는 새로운 워크로드의 의도하지 않은 사용과 같은 다양한 요인으로 인해 Git 또는 API에 대한 요청이 증가할 수 있습니다.
- 데이터베이스 쿼리 속도가 느립니다.
- 업그레이드 후 ElasticSearch 관리자 권한 서비스 리소스 사용량.
- 디스크 및/또는 IO 경합이 많은 IOPS 할당량에 도달합니다.
- 포화 상태의 작업자.
- 웹후크 배달 지연.
권장 사항
- 디스크 보류 중인 작업: 대기 중인 작업 수 그래프에서 급증하거나 지속적인 숫자를 찾습니다.
- 앱 요청/응답 패널을 확인하여 특정 서비스만 영향을 받는지 확인합니다.
- 업그레이드 후
ghe-check-background-upgrade-jobs를 실행하여 백그라운드 업그레이드 작업이 완료되었는지 확인합니다. - 예를 들어 URL:
grep SlowRequest github-logs/exceptions.log | jq '.url' | sort | uniq -c | sort -rn | head별 느린 요청 상위 10개를 확인하는 등 데이터베이스 로그에서/var/log/github/exceptions.log에서 느린 쿼리가 있는지 확인합니다(이를 위해 먼저 SSH를 사용하여 관리 셸에 로그인합니다 - 관리 셸(SSH)에 액세스 참조). - 특정 작업자에 대한 대기 중인 요청 그래프를 확인하고 활성 작업자 수를 조정하는 것이 좋습니다.
- 스토리지 디스크를 IOPS/처리량이 더 높은 디스크로 늘입니다.
- 백그라운드 처리를 위해 대기 중인 작업의 양을 확인합니다. 모니터 대시보드에 대한 정보을(를) 참조하세요.
상승된 오류율
가능성 있는 원인
- Git 또는 API에 대한 상승된 요청입니다. 과도한 리포지토리 복제, CI/CD 프로세스 또는 API 스크립트 또는 새로운 워크로드의 의도하지 않은 사용과 같은 다양한 요인으로 인해 Git 또는 API에 대한 요청이 증가할 수 있습니다.
haproxy서비스 장애 또는 개별 서비스의 사용 불가.- 시간이 지남에 따라 리포지토리 네트워크 유지 관리가 실패했습니다.
권장 사항
- 앱 요청/응답 패널을 확인하여 특정 서비스만 영향을 받는지 확인합니다.
haproxy로그를 확인하고 악의적 행위자가 원인일 수 있는지 확인합니다.- 실패한 리포지토리 네트워크 유지 관리 작업(
http(s)://[hostname]/stafftools/networks방문)을 확인합니다.