경고
이 문서에 설명된 파일만 제거합니다. 다른 항목을 삭제하면 데이터가 손실되거나 GitHub Enterprise Server 인스턴스를 사용할 수 없게 될 수 있습니다. 디스크 크기를 늘리려면 가동 중지 시간이 필요하므로 시작하기 전에 유지 관리 기간을 계획하세요.
Symptoms
GitHub Enterprise Server는 두 디스크에 데이터를 저장합니다. 즉, 루트 디스크는 /에 마운트되고 데이터 디스크는 /data/user에 마운트됩니다. 두 디스크 중 하나라도 가득 차면 서비스가 더 이상 디스크에 쓸 수 없으며 다음 중 하나가 표시될 수 있습니다.
- 웹 인터페이스는 500 오류를 반환합니다.
git push작업이 실패합니다.- 서비스가 시작되지 않거나 다시 시작한 후 응답하지 않습니다.
- 관리 콘솔에서 설정을 저장하거나 인스턴스를 업그레이드할 때 트리거되는 경우를 포함하여 구성 실행이 실패합니다. 자세한 내용은 명령줄 유틸리티을(를) 참조하세요.
또한 Elasticsearch는 디스크가 가득 차기 전에 데이터 디스크 사용량에 따라 조치를 취합니다. 사용량이 85%에 도달하면 Elasticsearch는 샤드 할당을 중지할 수 있으며 클러스터 상태가 적색이 됩니다. red 상태의 클러스터는 구성 실행을 차단하여 복제본에서 업그레이드 및 복제 시작 또는 중지를 차단합니다. 데이터 디스크 사용량을 85개%미만으로 유지하고 해당 수준에 도달하기 훨씬 전에 경고하도록 하여 60개%를 경고로 처리하고 75개%를 심각으로 처리합니다. 자세한 내용은 권장되는 경고 임계값을(를) 참조하세요.
원인
루트 디스크는 운영 체제 및 GitHub Enterprise Server 서비스에서 작성한 파일이 지워지는 것보다 더 빠르게 누적될 때 가득 찹니다. 가장 일반적인 원인은 빠르게 증가하는 로그 파일(회전된 로그 포함)과 자동 업데이트 검사로 다운로드되거나 수동으로 다운로드한 위치(예: /home/admin/)에 저장된 업그레이드 패키지입니다.
리포지토리, 패키지 및 GitHub Actions 데이터가 증가하여 프로비저닝된 용량을 초과하면 데이터 디스크가 가득 찹니다.
GitHub Actions이(가) 활성화된 경우 MSSQL 트랜잭션 로그는 데이터 디스크가 가득 차는 일반적인 원인입니다. 고가용성 구성에서 데이터베이스는 복제에는 FULL 복구 모델이 필요하므로 FULL 복구 모델에서 실행되며, 따라서 로그 공간은 백업이 실행될 때만 다시 사용할 수 있습니다. 백업이 충분히 자주 실행되지 않거나 실패하는 경우 로그는 데이터 디스크를 채울 때까지 또는 로그가 파일당 2TB 제한에 도달할 때까지 계속 확장되며 러너 등록도 중단됩니다.
문제를 확인하는 중
-
관리 셸에 SSH로 접속합니다. 자세한 내용은 관리 셸(SSH)에 액세스을(를) 참조하세요.
-
각 로컬 디스크에 사용되는 공간의 양을 확인합니다.
df -h -t ext4루트 디스크인
/에 탑재된 행의Use%열과 데이터 디스크인/data/user에 탑재된 행의Use%열을 읽습니다.Filesystem Size Used Avail Use% Mounted on /dev/sda1 98G 93G 1.1G 99% / /dev/mapper/ghe_user 251G 50G 189G 21% /data/user -
두 디스크 모두 여유 공간이 있는 것으로 표시되지만 서비스가 여전히 쓸 수 없는 경우 inode 사용량을 확인합니다. 여유 공간이 있는 디스크는 여전히 inode로 가득 차 있을 수 있습니다.
df -i -t ext4 -
공간을 사용하는 항목과 공간을 확보할 수 있는 기회를 파악합니다. 이 보고서는 루트 디스크와 데이터 디스크 둘 다에 대해 보고합니다.
ghe-check-disk-usage
문제 해결하기
출력을 기준으로 작업합니다 ghe-check-disk-usage. 공간 회수는 크기 조정보다 빠르며 가동 중지 시간이 필요하지 않으므로 출력 결과를 바탕으로 조치할 수 있는 경우 먼저 시도하세요. 그렇지 않다면 인스턴스에 더 많은 스토리지가 필요합니다.
루트 디스크의 공간 회수
-
출력에
/var/lib/ghe-updates아래 업그레이드 패키지가 나열된 경우, 이미 설치했거나 설치할 계획이 없는 릴리스에 해당하는 패키지는 제거하세요. 각 패키지는 여러 기가바이트입니다.PACKAGE을 파일 이름으로 바꾸십시오.sudo rm /var/lib/ghe-updates/PACKAGE -
출력에 업그레이드 패키지가
/home/admin아래 또는 수동으로 다운로드한 다른 위치에 나열되어 있는 경우, 이미 설치했거나 더 이상 필요하지 않은 패키지는 제거하세요.PACKAGE를 각각의 경로로 바꾸십시오.sudo rm PACKAGE -
출력에
.1아래에 있고/var/log또는.gz로 끝나는 큰 로그 파일이 나열되면 제거합니다. 이러한 항목은 이미 롤오버되었으며 더 이상 여기에 기록되지 않습니다.LOG-FILE를 각각의 경로로 바꾸십시오.sudo rm LOG-FILE경고
공간을 빠르게 확보할 수 있는 비상 조치로 간주하세요. 로그 볼륨을 생성하는 항목은 다루지 않으므로, 그것이 계속되면 로테이션된 로그가 다시 생기고 디스크가 다시 가득 찹니다. 그것들을 제거한 후에도 공간이 다시 사용되면 이 단계를 반복하지 말고 GitHub 지원에 문의하세요.
-
공간이 회수되었는지 확인하십시오.
df -h /
데이터 디스크의 공간 회수
MSSQL은 그 경우에만 실행되므로 GitHub Actions이(가) 사용 설정된 경우에만 적용됩니다.
출력에서 ghe-check-disk-usage의 MSSQL 트랜잭션 로그 분석을 확인합니다. 이 분석은 .ldf 아래에 /data/user/mssql/data로 끝나는 파일을 나열하고, 그중 비정상적으로 큰 파일에 플래그를 지정합니다. 이러한 로그는 백업이 내부 공간을 확보할 만큼 자주 실행되지 않을 때 증가하며 데이터 디스크가 가득 차는 일반적인 원인입니다.
출력에 대용량 트랜잭션 로그가 표시되면 원인을 확인하고 이를 잘라내는 방법은 MSSQL 트랜잭션 로그 잘라내기을 참조하세요.
스토리지 용량 늘리기
/data/user/tmp가 회전된 로그 파일, 업그레이드 패키지, ghe-check-disk-usage 아래의 이전 파일 또는 대형 MSSQL 트랜잭션 로그를 식별하지 못한 경우 회수하기에 안전한 것은 없으며 인스턴스에 더 많은 스토리지가 필요합니다. 공간을 회수한 직후 사용량이 다시 동일한 수준으로 돌아가는 경우에도 마찬가지입니다.
스토리지 용량 늘리기의 안내에 따라 루트 또는 데이터 디스크의 크기를 늘입니다.
재발 방지
한 번 용량 한계에 도달한 디스크 사용량은 대개 다시 그 상태가 되므로 두 디스크를 모두 모니터링하고 가득 차기 전에 조치를 취하십시오.
- 루트 및 데이터 디스크 사용량에 대해 경고하여 두 디스크가 모두 채워지기 전에 대응할 시간이 있도록 합니다.
- 최소 크기 조정보다는 사용량에 실제로 필요한 스토리지 양을 검토하세요. 자세한 내용은 리소스 할당 문제 해결을(를) 참조하세요.
- 회전된 로그가 루트 디스크를 다시 채우지 않도록 로그 생성 지점에서 로그 볼륨을 줄입니다. REST API를 폴링하는 클라이언트는 대용량 로그 데이터를 자주 생성하며 웹후크는 보다 효율적인 대안입니다. 자세한 내용은 웹후크 정보을(를) 참조하세요.
- GitHub Actions이(가) 활성화된 경우 일정에 따라 백업을 실행하고 정상적으로 완료되는지 확인하여 MSSQL 트랜잭션 로그가 통제되지 않게 증가하지 않도록 합니다. 자세한 내용은 백업 서비스 구성을(를) 참조하세요.
연락하기 GitHub 지원
이러한 단계로도 문제가 해결되지 않거나 이 단계들 중 어떤 것이라도 확실하지 않은 경우에는 계속하지 말고 GitHub 지원에 문의하세요. 자세한 내용은 지원 티켓 만들기을(를) 참조하세요.
이미 티켓을 연 경우 지원 번들을 첨부하면 GitHub 지원 문제를 더 빠르게 진단하는 데 도움이 됩니다. 자세한 내용은 GitHub 지원에 데이터 제공을(를) 참조하세요.
참고
지원 번들은 기본적으로 데이터 디스크에 기록됩니다. 데이터 디스크가 가득 차면 하나를 생성하지 못할 수 있습니다.