대형 Discourse 멀티사이트 최적화: 데이터베이스 및 Sidekiq 병목 현상

지원 자체 호스팅
,
1

Discourse 멀티사이트 구성을 최적화하는 방법에 대해 전문가의 조언을 구하고 있습니다. 현재 주요 클라우드 제공사에서 웹 VM 1대와 데이터베이스 VM 1대를 별도로 운영하고 있습니다. 두 서버 모두 사양이 충분하지만, 대량의 백그라운드 작업이 시스템에 과부하를 주며 데이터베이스에 무리가 가고 있는 것으로 보입니다.

현재 app.yml 구성은 다음과 같습니다:

  • UNICORN_WORKERS: 4
  • UNICORN_SIDEKIQS: 4
  • DISCOURSE_SIDEKIQ_WORKERS: 10
  • DISCOURSE_DB_POOL: 8

관찰 결과, 병목 현상은 연결 수의 하드 리밋에 도달하는 것이 아니라, 동일한 시점에 데이터베이스 자원을 두고 경쟁하는 작업의 양 자체가 과도하기 때문인 것으로 보입니다. Sidekiq 큐가 지속적으로 쌓이고 있어, 기본적인 관리 작업조차 사이트가 느리게 느껴집니다.

안정성과 성능을 위해 시스템을 튜닝할 수 있는 일반적인 접근법을 찾고 있습니다. 구체적으로 다음 사항에 대한 모범 사례를 이해하고 싶습니다:

  • Sidekiq 동시성: 멀티사이트 환경에서 DISCOURSE_SIDEKIQ_WORKERS는 데이터베이스에 무리가 가지 않으면서 높은 작업량을 처리하기 위해 어떻게 설정해야 하나요?
  • 큐 분리: 서로 다른 큐(예: critical vs. low 우선순위)를 처리하기 위해 별도의 Sidekiq 프로세스를 실행하는 것이 권장되나요? 이렇게 하면 무거운 작업이 더 시급한 작업을 차단하는 것을 방지할 수 있습니다.

현재는 주요 아키텍처 변경이나 다른 웹 서버로의 전환이 필요한 해결책보다는, 프로세스를 최대한 단순하고 리스크가 낮게 유지하기를 원합니다. 안전하고 효과적인 진행 방향에 대한 조언을 듣고 싶습니다.

감사합니다!

2

Discourse should be able to adapt those based on your system resources. Note that it is safe to re-run ./discourse-setup script if you have recently increased your system resources. The script can adapt to the increased resources and adjust your .yml accordingly

3

Sounds like you need fewer?

I’m pretty sure that it already knows to prioritize the high priority jobs.

4

@itsbhanusharma @pfaffman Thanks for your help. I appreciate you both taking the time to share your expertise.

5

If the database is the bottleneck, have you considered moving to larger instance type for your cloud database?