지금 재부팅을 할 수 없어서, 가능해지면 다시 보고하겠습니다. 최소 며칠은 걸릴 것 같습니다.
걱정해야 하나요? 더 많은 리소스를 할당해야 한다면 괜찮습니다.
네, 불안해해야 합니다.
여유가 거의 없고 디스크 캐싱을 위한 공간도 거의 없습니다.
하지만 리소스를 더 할당하기 전에 이 매우 이례적인 메모리 사용량의 원인을 파악해 보시는 것이 좋습니다.
지금은 할 수 있는 게 별로 없어요. 이동 중이라요. 이번 주말에 다시 돌아와서 무슨 일이 일어나고 있는지 꼭 알아볼게요. 힌트 주셔서 감사합니다 
간과된 재부팅이 원인이었던 것 같습니다. 서버를 재부팅했고, 현재 수치가 훨씬 더 좋아졌습니다.
root@discourse:~# free
total used free shared buff/cache available
Mem: 3927308 977624 2246208 42880 703476 2646836
Swap: 2097148 0 2097148
비슷한 상황에 다시 처하게 될 경우, 어떤 프로세스가 메모리를 사용 중인지 확인하는 것이 도움이 될 수 있습니다. 다음 링크의 출력 결과는 RAM 사용량 순으로 정렬되어 있습니다.
https://example.com/admin/upgrade#/processes
이 방법은 컨테이너에서 실행 중인 프로세스만 표시하는 것으로 보입니다. 커맨드 라인에서는 모든 컨테이너를 포함한 모든 프로세스의 사용량을 확인하려면 다음 명령어나 유사한 명령을 사용할 수 있습니다.
ps aux | sort -nr -k 4 | head -22
재부팅으로 메모리 부족 문제가 해결된다면, 어딘가에 통제 불능 상태(runaway)의 프로세스가 존재하여 (아마도 서서히) 문제가 발생하기까지 메모리 사용량이 계속 증가하고 있을 가능성이 높습니다.
수정: 아, RAM 사용량(RSS) 기준으로 프로세스를 읽는 방법에 대해 언급하고 있었네요. 이는 유용하지만, 이 경우 실제로는 가상 메모리 사용량에 더 관심이 있어야 합니다. 이를 위해 VSZ 열인 5열 기준으로 정렬해야 합니다.
이 Discourse 인스턴스는 몇 년 전에 처음 설정되었기 때문에, 스왑 파일 확인 기능이 도입되기 이전일 수 있습니다. 해당 코드 줄을 수동으로 적용하여 스왑 파일이 이제 생성되었습니다. 감사합니다.
Docker가 스왑 파일을 사용하도록 하려면 이 설정을 적용해야 합니까? 아니면 이 권장 사항의 목적은 무엇입니까?
vm.overcommit_memory에 대해 논의하는 내용을 찾았지만, 왜 그러한 변경이 필요한지 이해가 되지 않습니다:
이것은 Discourse 업그레이드와 관련이 없으며, Redis 실행과 관련된 것입니다.
저는 이 문제가 그 이상이라고 생각합니다. 설명을 드리겠습니다. 이 권장 사항은 Redis에서 나온 것이며, Redis가 이를 권장하는 이유는 프로세스 포킹(forking)이 상당량의 가상 메모리를 요구하기 때문입니다. Redis는 백그라운드 저장을 수행하기 위해 포킹을 하지만, 실제로는 그 가상 메모리가 필요해질 일이 거의 없습니다.
이것은 많은 유닉스 애플리케이션에서 일반적인 현상입니다. 포킹을 하지만 메모리 사용량이 두 배로 증가할 필요는 없습니다. 많은 애플리케이션에서 이러한 패턴이 일반적이며, 이 설정이 컨테이너 내 모든 프로세스의 동작을 변경하는 커널 설정이므로, 가상 메모리가 압박을 받는 상황에서 실패를 성공으로 전환할 수 있습니다.
많은 사용자가 사용하는 소형 저가 인스턴스에서는 가상 메모리가 종종 압박을 받습니다. 특히 업그레이드나 재빌드 과정에서는 더욱 그렇습니다.
따라서 이 설정을 변경하면 업그레이드가 성공할지 실패할지에 영향을 미칠 수 있으며, 특히 가상 메모리 요구량이 recently 증가한 변경 사항이 있는 경우 더욱 그렇습니다.
기본적으로 커널은 충족할 수 없는 할당을 거부합니다. 이 조정(tweak)을 적용하면 해당 할당을 허용하게 되며, 이로 인해 실패가 방지될 수도 있고, 할당이 실제 사용으로 전환될 때 나중에 실패가 발생할 수도 있습니다.
RAM과 스왑의 총 용량이 충분히 크다면 이 설정을 변경할 필요가 없습니다. 총 용량이 크지 않다면, 이 설정을 변경하는 것이 도움이 될 수 있습니다.
free 명령을 사용하면 설정된 스왑 양과 그 중 사용 중인 양을 확인할 수 있습니다. 해당 명령을 실행한 직후부터 스왑이 사용 중일 것이라고 생각합니다.
사용 가능한 가상 메모리 용량을 늘리기 위함입니다. (즉, RAM과 스왑의 합계입니다.) RAM이 부족해지면 성능 문제가 발생하기 시작합니다. 하지만 가상 메모리가 부족해지면 프로세스가 시작되지 않거나 종료되거나 강제 종료됩니다. 상황이 매우 심각해집니다.
RAM과 디스크 용량이 모두 작은 환경에서는 대량의 스왑을 추가할 여유가 없을 수 있지만, 2GB가 좋은 최소치인 것 같습니다. (RAM이 16GB라면 스왑이 전혀 필요 없을 수도 있지만, 그것은 별개의 이야기입니다. 문제가 프로세스 실패와 관련된 경우, 두 가지를 합친 총량이 중요합니다.)
아하. 나는 그걸 대략 이해하고 있다고 생각했지만, 아주 좋은 설명이네요. 그래서 제가 만든 모든 설치 환경 클라이언트용 VM에서 이 설정을 적용해 왔습니다.
discourse-setup이 스왑을 생성할 때 이 설정들을 변경하도록 해야 하지 않을까요?