메모리가 최대치에 도달하고 시스템이 기본적으로 CPU가 100%이고 사용 가능한 RAM이 [거의] 없어서 죽어서 AWS ERP 서버에서 4배의 충돌이 발생했습니다.
Ubuntu 18.04.5 LTS(GNU/Linux 5.4.0-1060-aws x86_64)(AWS AMI)
GitHub 작업 도중에 이런 일이 세 번 발생했습니다. 작업은 데이터베이스 가져오기를 수행한 다음 Slack 알림을 수행하는 것이었습니다. 따라서 문제가 발생한 단계 중 하나라고 생각할 수 있지만 이상하게도 모든 단계가 정상적으로 완료되었습니다. 데이터베이스는 괜찮았고 여유 알림이 푸시되었습니다.
GitHub 자체는 러너와의 연결이 끊어졌고 작업이 완료된 후에도 가상 메모리가 지붕을 통과했습니다.
네 번째로 NOTHING이 실행 중일 때 이런 일이 발생했습니다. 실제로 서버는 아무 일도 일어나지 않고 유휴 상태였습니다. 그러나 이에 대한 로그나 "상위" 스크린샷은 없지만 한 번은 그 장면을 포착했습니다.
따라서 시스템은 4G RAM을 갖춘 AWS VM입니다. 나는 이 시스템을 설정한 SI가 스왑 공간이 없도록 구성되었다고 믿습니다. 메모리 누수가 발생하면 시스템이 메모리 부족을 보고하고 정정 조치를 취하기를 원한다는 점에서 이는 서버에 대해 틀림없이 정확합니다[매우 틀림없이]. 메모리 누수가 있으면 어쨌든 결국 죽을 것입니다.
단기적으로 RAM을 두 배로 늘리라는 요청을 받았습니다. 이는 로드가 매우 적은 시스템(대량 일괄 작업을 수행할 때 일반적으로 약 2G의 RAM만 사용하여 실행)이므로 다소 불필요하며, 솔직히 GitHub Runner.Worker가 4GB 시스템에서 최대 7GB RAM을 사용하는 경우 왜 그렇습니다. 8GB VM에서 최대 16GB RAM을 확보할 수는 없겠지만, 다시 충돌이 발생하는지 살펴보겠습니다. TFG의 스왑 구성을 변경하는 것을 반대하지는 않지만 해결되었는지는 확실하지 않습니다.
나는 이것을 GitHub에 보고했지만 3주가 넘는 시간 동안 아무런 조치도 취하지 않은 후에 여기에서 확인하고 아이디어나 수정 사항이 있는 사람이 있는지 확인하겠습니다.
감사합니다,
== 존 ==