안녕하세요!
Docker로 Discourse를 운영하고 있는데, RAM 사용량이 과도할 때 스왑을 전혀 사용하지 않는 것 같습니다. 이로 인해 재빌드를 시도하면 fatal error: out of memory allocating heap arena map 오류가 발생하거나 크래시가 납니다. 몇 시간마다 재부팅하지 않으면 정상적으로 작동하지 않는 것 같습니다.
이 문제를 해결하는 방법을 아시는 분 계신가요?
감사합니다,
Kian
리눅스를 사용 중이라고 가정할 때, free -h 명령어는 무엇을 표시합니까? (가능하다면 재시작 직후와 오류 발생 직전에 실행해 주세요.)
아마도 swappiness가 0으로 설정되어 있는 것일까요?
cat /proc/sys/vm/swappiness
안녕하세요!
40으로 되어 있었는데, 이제 60으로 설정했습니다.
시스템은 항상 RAM의 대용량 청크를 캐시하며, RAM 사용량이 높더라도 스왑은 절대 사용되지 않습니다.
출력 결과 중 주목해야 할 두 가지 부분은 사용 가능한 메모리 5.5GB와 사용 중인 스왑 0B라고 생각합니다. 아니면 무료 스왑 9GB일 수도 있겠네요. 5.5GB + 9GB는 얼마나 여유 공간이 있는지를 알려줍니다. 버퍼와 캐시에 사용된 메모리량은 동적으로 변하며, 절대 부족 현상을 일으키지 않아야 합니다.
고장까지 남은 시간이 단 몇 시간에 불과하다면, vmstat 5를 실행하여 출력을 캡처하고, 마지막 순간까지 볼 수 있도록 하는 것이 좋겠습니다. 저는 과거에 크론 작업을 통해 10분마다 vmstat 5 5를 로그 파일에 기록하는 방식을 사용했습니다.
잘못 동작하는 소프트웨어가 모든 사용 가능한 리소스를 매우 빠르게 소진할 수도 있습니다. 이 경우 몇 분 간격으로 ps uax를 기록하여 중요한 순간의 스냅샷을 몇 개 확보할 수 있다면 매우 유용할 것입니다.
또 다른 제한 사항이 작용하고 있을 수도 있습니다. 아마도 특별한 구성 없이 다른 프로그램이 실행되지 않는 순수한 OS에 설치된 상태일 것 같은데 맞습니까?
안녕하세요!
vmstat 5를 10분마다 로그 파일에 기록하려면 어떻게 해야 하나요? 또한 ps uax 명령어의 출력을 몇 분마다 로그에 기록하는 방법도 알고 싶습니다.
네, 기본 설치된 18.04 Ubuntu 서버 환경입니다. apache, docker 등만 설치되어 있습니다.
방금 Varnish Cache가 설치되어 있다는 것도 떠올랐는데, 이게 캐시된 RAM을 설명하는 것 같아. 그런데 Discourse가 왜 스왑도 사용하지 않는지 모르겠어. 며칠 전에 docker 명령으로 스왑 한도를 설정해 봤는데, 아무런 효과가 없었거든.
크론(cron)이 더 나은 방법이지만, 간단하고 저렴한 원라이너(one-liner)를 소개합니다.
sh -c 'rm -f /tmp/stop; while [ ! -e /tmp/stop ]; do (date; uptime; free; ps faux; vmstat 5 5) >> /var/log/monitor.log; sleep 600; done' &
이것은 영원히 실행됩니다: 중지하려면 touch /tmp/stop을 실행하세요.
로그는 /var/log/monitor.log에 나타납니다 - 마지막 상황을 보려면 tail -99을 사용하거나, less로 페이지를 넘겨볼 수 있습니다. 어딘가에서 문제가 발생하고 있음을 보여주는 로그 섹션을 찾아야 합니다.
여기서 스스로에게 잘못된 질문을 하고 있는 것 같습니다. 버퍼 사용과 스왑 사용을 포함한 가상 메모리를 관리하는 것은 리눅스 커널입니다. free 명령이 스왑이 구성된 것으로 보고한다면, 그것은 정상적인 상태이며 여러분이 할 일은 없습니다.
여러분의 진정한 질문은, 왜 내 discourse가 잘 작동하지 않는지, 왜 재시작이 필요한지, 그리고 왜 fatal error를 보고 있는지에 대한 것입니다.
이 주제를 다음과 같이 제목을 변경하는 것을 강력히 권장합니다.
“fatal error: out of memory allocating heap arena map” 오류는 왜 발생하는가?
또한, 여러분이 몇 가지 서로 다른 관찰 결과를 가지고 있는 것 같아 걱정됩니다:
- 때때로 discourse가 충돌합니다.
- 재빌드할 때 때때로 "fatal error:… heap arena map"를 봅니다.
- 몇 시간마다 재부팅이 필요합니다.
그리고 이 관찰 결과들이 정확히 어떻게 상호작용하는지 저에게는 명확하지 않습니다.
- discourse가 충돌했다고 믿는 근거는 무엇인가요: 관찰된 현상은 무엇인가요?
- 재빌드할 때 항상 "fatal error:"를 보나요?
- 왜 재빌드를 하고 있나요?
- 재부팅을 유도하는 것은 무엇이며, 여기서 재부팅은 서버를 재부팅하는 것을 의미하나요?
답변을 들을 수 있으면 좋겠습니다!
음, 구체적으로 어떤 작업을 하셨나요?
docker stats --no-stream --no-trunc
명령어로 확인했을 때 MEM USAGE / LIMIT과 MEM % 값은 어떻게 나와 있나요?
(제 경우, LIMIT 값은 기기의 물리적 메모리 용량보다 약간 적은 값입니다. 이는 컨테이너 내부에서 실행되는 프로세스가 스왑을 유발할 가능성이 낮다는 것을 의미하며, 스왑이 거의 또는 전혀 사용되지 않더라도 프로세스가 메모리 할당에 실패할 수 있음을 시사합니다.)
안녕하세요!
Discourse가 충돌한 것 같습니다. 도메인에 접속하면 Nginx 502 Bad Gateway 오류가 발생하거든요. 그런데 Docker 컨테이너는 여전히 실행 중입니다.
네, 가끔 그런 경우가 있습니다.
502 Bad Gateway 오류가 한동안 해결되곤 해서 다시 빌드해 봤습니다.
서버를 재부팅해서 오류가 해결되는지 확인해 보겠습니다. 가끔은 잘 동작하기도 하지만, 대부분은 안 되고 다시 빌드해야 한동안 해결되는 식입니다.
오류 로그도 곧 가져다 드리겠습니다.
/var/log/monitor.log을 실행하고 tail -99를 사용하면 -bash: /var/log/monitor.log: Permission denied 오류가 발생합니다
(스크린샷을 보니 "app"이라는 컨테이너의 메모리 한도가 7.8G이고 사용량이 3%에 불과하므로 문제없어 보입니다. 수정: 하지만 CPU 사용량이 100%인 점이 의심스러울 수 있습니다.)
그 로그 파일의 끝부분만 확인하면 되므로,
tail -199 /var/log/monitor.log
를 사용하면 필요한 정보를 얻을 수 있을 것입니다. 하지만 더 많은 부분을 확인해야 할 수도 있습니다: 로그 파일을 압축해서 첨부하거나, 다른 방식으로 공유해 주실 수 있을까요? 로그 파일의 크기는 얼마나 되나요?
ls -l /var/log/monitor.log
100%가 1코어라고 생각합니다. 시스템이 정상적으로 작동하니까요.
log.txt (25.0 KB)
로그의 199줄입니다.
monitor.txt (39.3 KB)
전체 로그입니다 
감사합니다. 모두 정상적으로 보입니다. 하지만 이것은 단일 스냅샷일 뿐입니다. 정상적으로는 10분마다 로그에 새로운 섹션이 추가되어야 합니다. Discourse에서 문제가 발생하는 것을 확인한 후, 마지막 몇 개의 섹션을 공유해 주세요.
솔직히 말씀드리자면, 무슨 일이 일어나고 있는지 알 수 없습니다.
3개의 Unicorn 프로세스가 CPU를 많이 사용 중인 것을 확인했는데, 왜 그런지 이유를 알 수 없습니다.
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME
COMMAND
x 434 51.9 2.8 443732 234144 ? Sl 18:26 0:11 \_ unicorn master -E production -c config/unicorn.conf.rb
x 662 103 3.6 8877408 301148 ? Rl 18:26 0:08 | \_ discourse sidekiq
x 686 99.7 3.6 8873312 301916 ? Rl 18:26 0:06 | \_ unicorn worker[0] -E production -c config/unicorn.conf.rb
x 731 94.3 3.6 8873312 294368 ? Rl 18:26 0:05 | \_ unicorn worker[1] -E production -c config/unicorn.conf.rb
x 744 77.2 3.3 8873312 276788 ? Rl 18:26 0:03 | \_ unicorn worker[2] -E production -c config/unicorn.conf.rb
top을 실행한 뒤 shift+m을 눌러 RAM 사용량 기준으로 정렬하면 어떤 프로세스가 가장 많은 RAM을 사용 중인지 확인할 수 있습니다. 결과를 여기에 공유해 주시겠어요?
