업그레이드 중 전체 시스템이 멈춤

지원 자체 호스팅
1

AI 플러그인을 시도해 본 후(그리고 나중에 다시 제거한 후)부터, /admin/upgrade 실행 시 내 머신이 완전히 멈추는 현상이 발생하고 있습니다.

매번 그런 것은 아니지만, 대략 80%의 확률로 발생합니다.

보통은 내 EC2 인스턴스 전체가 동결되어 AWS EC2 웹 UI를 통해 하드 리부트를 해야 합니다.

오늘도 다시 멈췄습니다. 놀랍게도 완전히 동결되지는 않았습니다. 루트 URL을 열면 이제 다음과 같은 내용이 표시됩니다:

Oops

이 토론 포럼을 구동하는 소프트웨어에서 예상치 못한 문제가 발생했습니다. 불편을 끼쳐드려 죄송합니다.

오류에 대한 자세한 정보는 로그에 기록되었으며, 자동 알림이 생성되었습니다. 확인해 보겠습니다.

추가 조치는 필요하지 않습니다. 하지만 오류 상태가 지속된다면, 오류를 재현하는 단계 등을 포함한 추가 세부 정보를 사이트의 피드백 카테고리에 토론 주제를 게시하여 제공할 수 있습니다.

이제 다시 리부트하고, 지금까지 문제를 해결해 주었던 sudo ./launcher rebuild app 같은 일반적인 작업을 수행해 보겠습니다. 오늘도 다시 이 방법으로 해결되길 기원합니다.

제 질문

누군가 로그 파일이나 이와 같은 것들을 어디서 확인해야 하는지, 적어도 왜 이런 현상이 발생하는지에 대한 오류 메시지를 얻을 수 있는 힌트를 줄 수 있을까요?

2

공식 AI 플러그인인가요?

콘솔에서 실행해서 어디서 막히는지 확인하고, 로그를 공유해 주세요.

3

네, 공식 플러그인입니다.

app.yml에서 플러그인을 다시 제거한 뒤 재빌드하여 삭제했습니다. 이렇게 하는 것만으로는 충분하지 않나요?

여기서 "이 명령"은 sudo ./launcher rebuild app을 의미하나요?

4

서버 사양이 어떻게 되나요?

개인적으로 요즘에는 온라인 업그레이드를 하려면 최소 4GB 서버 + 2GB 스왑이 필요하다고 봅니다.

5

저는 2 vCPU와 4 GiB RAM을 갖춘 AWS EC2 “t2.medium” 인스턴스를 사용하고 있습니다.

HDD 용량은 100 GiB이며, 사용 가능한 공간은 60 GiB입니다.

도움이 된다면 "t2.medium"을 더 큰 인스턴스 유형으로 업그레이드할 수도 있습니다.

공식 AI 플러그인을 테스트하기 전까지는 이 구성이 수년 동안 매우 안정적으로 작동했는데, 플러그인을 제거한 후부터 업그레이드 중에 이런 중단 현상이 발생하는 것이 이해가 되지 않습니다.

6

또 다른 변화가 있습니다. 업그레이드하려는 소프트웨어의 버전입니다. 최근에는 메모리 사용량이 더 많이 증가했습니다. 따라서 두 가지 중 하나일 수 있다고 생각합니다.

메모리 부족이 문제인지 테스트하는 가장 쉬운 방법은 RAM이 더 많은 인스턴스로 일시적이고 되돌릴 수 있는 업그레이드를 수행하는 것입니다. 단, 재부팅이 몇 번 필요할 수 있습니다. 다른 방법은 스왑을 추가하는 것이며, 이 역시 되돌릴 수 있습니다.

7

스왑을 추가해 보겠습니다.

8

감사합니다, 여러분. 어떻게 하는지 구글로 검색한 후 해보겠습니다. :slight_smile:

업데이트 1

이제 8GiB의 스왑을 추가했습니다:

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       290Mi       2.9Gi       1.0Mi       677Mi       3.3Gi
Swap:          8.0Gi          0B       8.0Gi

다음 업그레이드 몇 번 후 이 문제가 해결되었는지 여부에 대해 이곳에서 업데이트를 게시하겠습니다.

업데이트 2

방금 /admin/upgrade를 실행하고 RAM 사용량을 모니터링했습니다:

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       1.4Gi       1.5Gi        50Mi       891Mi       2.0Gi
Swap:          8.0Gi       200Mi       7.8Gi

업그레이드가 성공적으로 완료되었습니다. :tada: 이 상태로 유지되길 바랍니다.

업데이트 3

수일과 여러 번의 업그레이드 후에도 다시는 정지 현상을 경험하지 않았습니다.

따라서 스왑이 해결책이었다고 생각합니다. 이 문제에 대해 도움을 주신 모든 분께 다시 한번 감사드립니다.

9

조금 주제에서 벗어난 이야기지만, 정말 이해하고 싶습니다. 200MB를 사용하던 스왑이 왜 2GB의 사용 가능한 RAM이 있을 때 도움이 된 걸까요?

(인치 단위 세계에서 SI 단위계가 10진법을 사용해서 혼동할 수 있다는 점은 이해합니다. 하지만 왜 Mi를 사용하는 거죠? Gi가 기가(giga)에서 줄인 형태라면 이해가 되는데, 메가(mega)는 Me가 되어야 하지 않나요?)

10

Mi는 미비바이트(Mibibytes), Gi는 기비바이트(Gibibytes)를 의미할 것 같습니다.

11

감사합니다. 몰랐어요. 당연한 거죠. 그런데 이건 메비바이트예요 :slight_smile:

그리고 이걸 몰랐던 다른 분들을 위해 :smirking_face:

12

원래 문제는 아마도 머신이 메모리를 모두 소진했을 때 프로세스가 종료되었기 때문일 것입니다(오버킬러(OOM killer)에 주의하세요). 스왑을 추가하면 메모리가 고갈되지 않게 됩니다. free 명령의 두 출력 결과가 기계의 스트레스가 가장 컸던 순간에 매우 신중하게 캡처되지 않았다면, 전체 상황을 설명하지 못할 수 있습니다. 저는 피크 스왑 사용량이 더 흥미롭다고 생각합니다.

또한, MKJ’s Opinionated Discourse Deployment Configuration에서 언급된 커널 튜너블 값에 대한 질문도 있습니다. 저는 이 값을 올바르게 설정해 두었지만, 많은 사람들이 올바르게 설정하지 못했을 수 있습니다.

메모리 오버커밋은 Redis와 큰 관련이 없다는 점을 언급할 가치가 있습니다. 단지 Redis가 이 값이 올바르게 설정되어야 한다는 힌트를 친절하게 제공해 줄 뿐입니다.

13

다시 /admin/upgrade를 시작했고, 대략 1초마다 tree -h를 수동으로 실행하기 위해 셸을 열어 두었습니다.

찾을 수 있었던 가장 높은 메모리 사용량 값은 다음과 같습니다:

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       3.2Gi       120Mi        80Mi       542Mi       266Mi
Swap:          8.0Gi       276Mi       7.7Gi

업그레이드가 성공적으로 완료되었습니다.

14

마지막 스크린샷이 가장 메모리 부하가 심한 순간이었다고 가정하면, 빌드 시 4GB는 정말 한계치에 가깝습니다.

그리고 또 하나 이해가 안 되는 점이 있습니다. 왜 다른 사람들은 메모리 부족 문제를 겪는데, 플러그인과 컴포넌트를 많이 사용하는 저는 아무런 문제가 없었을까요? :thinking: 이 차이는 무엇 때문일까요?

여기서 had(과거형)를 사용한 이유는, 요즘은 AI 때문에 8GB를 사용 중이기 때문입니다 (저에게는 가격 차이가 그렇게 중요하지 않았지만, 이건 또 다른 이야기입니다).

이 스레드를 다른 곳으로 옮기는 것이 좋을까요, 아니면 스왑 사용이 왜 도움이 되는지에 대한 설명으로 보고 있을까요?

어쨌든, 다른 초보자를 위해 메모리 부족과 그 원인에 대해 조금 이야기하는 이 예시를 공유합니다:

업그레이드가 실패할 때 메모리 부족은 매우 자주 질문되는 FAQ입니다. 하지만 그 이유는 거의 설명되지 않는 편입니다.

15

@Jagster @uwe_keim 다음 명령어의 출력을 보고해 주실 수 있을까요?

cat /proc/sys/vm/overcommit_memory 
cat /sys/kernel/mm/transparent_hugepage/enabled

제 시스템에서는 다음과 같습니다.

# cat /proc/sys/vm/overcommit_memory 
1
# cat /sys/kernel/mm/transparent_hugepage/enabled 
always madvise [never]
16 
$ cat /proc/sys/vm/overcommit_memory
0

그리고

$ cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never
17

@uwe_keim 님, 감사합니다. 스왑이 사용되지 않는 것처럼 보였지만, 스왑을 추가해야 했던 이유가 바로 그 커널 튜너블 때문이라고 추정해 보겠습니다. (총 사용 가능 메모리는 RAM+스왑이므로, 대량의 RAM을 추가해야 했다면 같은 원리가 적용됩니다.)

18

권장 사항이 있으시면 언제든 서버 설정을 변경할 수 있습니다.

19 
root@foorumi-hel:/var/discourse# cat /proc/sys/vm/overcommit_memory
0
root@foorumi-hel:/var/discourse# cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never
20

권장합니다!

이것은 향후 재부팅 시 문제를 해결해 줍니다(현재 상태를 확인하지 않고 파일을 덮어쓰는 점에 유의하세요):

echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
echo 'vm.overcommit_memory=1' > /etc/sysctl.d/90-vm_overcommit_memory.conf
sysctl --system