문제: 멀티사이트 인스턴스에서 대량 가져오기 후 Sidekiq 처리가 매우 느림

현재 단일 앱에서 멀티사이트 구성으로 여러 Discourse 사이트를 운영 중입니다. 최근 6개 사이트에서 수십만 명의 사용자를 일괄 가져왔습니다. 가져오기 작업 이후 Sidekiq의 백그라운드 작업 처리 속도가 매우 느려졌습니다. Sidekiq 대시보드에서 막대한 작업 대기열이 표시되고 있으며, 작업이 처리되는 속도가 예상보다 훨씬 느립니다.

환경 정보:

  • VM이 16 CPU / 16GB RAM으로 업그레이드되었습니다.
  • 그러나 Sidekiq 인터페이스에서는 스레드가 5개만 보이며, 리소스의 일부만 사용되고 있는 것으로 보입니다.
  • 메인 가져오기 큐(멀티사이트 부모인 “nursingjobs”)는 모든 자식 사이트의 작업을 처리하고 있지만, 작업 처리량(throughput)이 매우 낮습니다.
  • 서버 지표: CPU는 때때로 80~90%, 메모리는 약 6.7/7.2GB 사용 중입니다.

원하는 내용:

  • 가져오기 후 대량의 대기열을 해소하기 위해 Sidekiq/백그라운드 작업 처리 속도를 높이고자 합니다.
  • Discourse가 사용 가능한 모든 리소스(CPU/RAM)를 활용하도록 보장하고자 합니다.
  • 조정해야 하는 스레드/프로세스 제한이 있는지 이해하고자 합니다.

질문:

  1. 가져오기 후 높은 처리량을 위해 Sidekiq/Discourse를 설정하는 최선의 방법은 무엇인가요?
  2. 대규모 멀티코어 시스템에서 UNICORN_SIDEKIQS와 DISCOURSE_SIDEKIQ_WORKERS에 권장되는 설정은 무엇인가요?
  3. Sidekiq 동시성(concurrency)을 높일 때 DB 풀 오류를 피하기 위해 조정해야 하는 Postgres 또는 기타 app.yml 설정이 있나요?
  4. 가져오기 후 거대한 Sidekiq 대기열을 빠르고 안전하게 해소하는 모범 사례가 있나요?

도움이 된다면 Sidekiq 통계/스크린샷을 제공할 수 있습니다!

이 모든 질문에 대한 답은, 대체로 DISCOURSE_SIDEKIQ_WORKERS 값을 높이는 것입니다.

여유로운 CPU 자원이 많이 남아 있다는 것을 알고 있으므로, 이 값을 32 정도로 높여 보세요. 해당 설정을 일정 시간 동안 적용한 후에도 여전히 CPU 자원이 많이 남아 있다면, 값을 더 높이는 것도 괜찮습니다.

정상적인 운영을 위해 이 값을 8이나 12 정도로 다시 낮추는 것도 괜찮을 것입니다.

Postgres의 max_connections 값이 충분한지 확인하세요. 멀티사이트를 운영하고 있으므로 이미 이 값을 높여 두셨을 가능성이 크지만, 지속적으로 모니터링해 주세요.

고맙습니다 @supermathie 이제 작동합니다.
아래와 같이 config를 업데이트했습니다

  UNICORN_WORKERS: 8
  UNICORN_SIDEKIQS: 7
  DISCOURSE_SIDEKIQ_WORKERS: 10
  DISCOURSE_DB_POOL: 20

그리고 CPU를 다음으로 증가시켰습니다

8vCPU
16GB Memory