로그에서 이러한 오류가 점점 더 많이 확인됩니다. /var/discourse/containers/app.yml 파일에서 Sidekiq의 RSS 한도를 조금 올려야 할까요?
env:
SIDEKIQ_MEMORY_KILLER_MAX_RSS: 700
아니면, 이는 정상적인 현상이므로 무시해도 될까요?
free -h
total used free shared buff/cache available
Mem: 5.8Gi 3.6Gi 227Mi 310Mi 2.0Gi 1.6Gi
Swap: 1.0Gi 42Mi 981Mi
제가 실제로 효과를 본 방법입니다.
메모리 사용량을 모니터링하고 설정을 조정하면서, 빈번하게 발생하던 “Sidekiq is consuming too much memory…” /로그 메시지를 없앨 수 있었습니다.
/var/discourse/containers/app.yml 파일에서 다음과 같이 변경했습니다:
UNICORN_WORKERS: 4
UNICORN_SIDEKIQ_MAX_RSS: 700
처음에는 UNICORN_WORKERS를 8로 설정해 두었는데, 이는 너무 공격적인 설정이었으며 Sidekiq, PostgreSQL, Redis, 그리고 운영체제에 매우 적은 여유 공간만 남기고 있었습니다.
워커 수를 4로 줄이면서 상당한 양의 메모리가 비어났습니다.
그 후 Sidekiq의 RSS 한도를 기본값(약 500 MB)에서 700 MB로 높였는데, 이렇게 하면 자동 재시작되기 전에 Sidekiq가 조금 더 여유 있게 동작할 수 있습니다.
현재까지 Sidekiq는 안정화되었고, 메모리 사용량도 훨씬 안전한 수준으로 유지되고 있습니다. 사용 중 메모리에서 캐시 및 사용 가능 메모리로 1 GB가 조금 넘는 양이 이동했습니다.
이 정보가 도움이 되거나, 비슷한 문제를 겪고 있는 다른 분들에게 무엇을 살펴봐야 하는지 힌트가 될 수 있기를 바라며 여기에 남겨 둡니다. 1주일의 가동 시간 이후에도 이 상태가 유지되고 더 안정적일지 지켜볼 예정입니다. 만약 그렇다면 해결로 표시하겠습니다.
나도 얼마 전에 같은 메시지를 받았는데, 당신처럼 (1GB로) 설정을 조정했고 그 후로 에러가 다시 나오지 않았습니다 
변경 사항이 정상적으로 작동하는 것을 확인했습니다. Sidekiq의 마지막 재시작 시각은 11월 10일 오후 12:48이었습니다.
오늘의 메모리 통계:
이 포럼에는(위에서 링크함) 도움이 되는 유익한 스레드들이 있었습니다. 비슷한 문제를 겪고 있는 다른 분들에게도 도움이 되기를 바랍니다.
조사 결과, 제 포럼의 트래픽은 워커 8개가 필요할 정도로 많지 않다는 것을 알게 되었습니다. 워커 2개만으로도 충분했을 것입니다.
그러나 제 서버에서는 메모리가 현재 및 미래의 주요 병목 현상인 것 같습니다. 그럼에도 불구하고 VM은 동일한 크기로 유지할 계획입니다. 스왑이 매우 빠른 NVMe RAID 10에 구성되어 있으므로, 향후 트래픽이 증가하여 필요할 경우 zswap을 추가하고 몇 년 후 이 스레드를 업데이트할 것입니다.
