그렇다면 UNICORN WORKER는 2*vCPU여야 한다는 모든 주장이 틀린 건가요?
제 서버 사양은 Intel Xeon E5-2686 v4 @ 2.30GHz—24vCPU+32GB Ram입니다.
UNICORN WORKER는 몇 개로 설정해야 하나요?
8개인가요, 아니면 48개인가요?
제 사이트는 7,000명 이상의 사용자와 약 1,000명의 일일 활성 사용자가 있습니다. 사용자들은 하루에 3,000~7,000개의 게시물을 작성합니다. 크롤러와 익명 사용자를 포함하여 커뮤니티의 일일 페이지뷰는 12만~20만 건입니다.
이는 많은 요인에 따라 달라집니다. RAM 대비 데이터베이스 크기가 어느 정도인지, 로그인한 트래픽과 익명 트래픽의 비율, Sidekiq 큐를 더 바쁘게 만드는 플러그인이 있는지, YJIT를 실행 중인지 여부 등이 그것입니다.
간단한 방법은 피크 시간대에 MiniProfiler 데이터를 확인하고, 포럼을 둘러보며 성능이 더 나빠졌는지 살펴본 후 병목 현상을 식별하는 것입니다.
해당 CPU가 오래된 모델이므로, 모든 요청이 평소보다 더 오래 걸릴 것이므로 평소보다 더 많은 Unicorn 워커 수로 시작하는 것이 좋습니다. 하지만 PostgreSQL과 Redis를 같은 서버에서 실행 중이라면 워커를 너무 많이 실행하여 이들에게 리소스를 빼앗아서는 안 됩니다.
처음에는 16개의 워커를 실행해 보고 사이트의 성능을 평가해 보세요.
Unicorn 워커가 무엇을 하는지에 대한 단순하고 직관적인 설명이 있을까요? 제 느낌으로는 모든 사용자 페이지 요청이 Unicorn 워커를 통해 처리되어야 하는 것 같습니다. 워커가 충분하지 않으면 사용자는 기다려야 하고, 워커가 너무 많다면… 음, RAM 사용량이 조금 증가할 수 있겠네요.
이들은 애플리케이션 웹 서버입니다.
10년 된 CPU가 노후화의 징후를 보이고 있는 것 같습니다. Unicorn 워커를 늘리면 동시에 더 많은 사용자를 처리할 수 있지만, 개별 요청의 속도를 높이는 데는 도움이 되지 않습니다.
YJIT를 활성화해 보시겠어요?
사용자님의 하드웨어 사양을 고려하면, 로그인 상태의 목록/최신 시간의 평균이 앱에서 약 150ms, SQL에서 80ms 정도 나올 것으로 예상합니다.
처음에는 워커 12개를 설정하고 그 상태에서 어떻게 동작하는지 확인해 보세요. 가장 좋은 방법은 메트릭을 추적하는 것입니다. 워커를 더 추가해야 하는지 알고 싶다면, 앱 워커를 기다리며 대기열에 쌓이는 요청이 있는지 확인해 보세요.
Discourse 자체가 Prometheus 익스포터로 내보내는 메트릭을 추적하고 계신가요? 이를 통해 인스턴스의 전반적인 성능을 잘 파악할 수 있습니다.
익명 사용자와 일반(관리자가 아닌) 사용자의 성능 수치는 어떻게 되나요?
(웃음을 멈추고 호스팅 제공업체에 로그인하는 중 … )
와, 이거 아직 기본 설정이 아니었나요??
수정: 아, 물론 오래된 app.yml로 빌드한 뒤 업데이트를 안 하셨을 수도 있겠네요
저희 호스팅에서는 기본으로 설정되어 있지만, RAM이 제한적인 환경에서 실행하는 사용자가 있을 수 있어 기본값으로 설정하기가 다소 어렵습니다…
그럼에도 불구하고, 저희 JS 빌드는 Discourse 자체보다 훨씬 더 많은 RAM을 사용하므로, JS 에셋을 빌드할 수 있는 사람은 여유로운 RAM을 충분히 가지고 있다고 볼 수 있습니다 ![]()
이 사진들을 보면 워커를 몇 개로 설정해 두셨나요?
저라면 이렇게 하겠습니다.
- 약간의 큐잉(대기열)이 발생하므로 워커 수를 조금 늘리세요.
- 웹 처리 시간이 꽤 느리므로 YJIT를 활성화하세요.
현재 워커는 8개만 있으며, YJIT가 이미 활성화되어 있습니다.
워커를 몇 개로 늘려야 하나요?
참고로 Falco가 해당 추천을 내릴 때 참고했던 내용은 다음과 같습니다:
8개에서 12개로 늘리는 것을 추천합니다. 여유 공간을 확보해 줄 뿐만 아니라, 대기열을 해소하는 데 도움이 될 것입니다.
참고로, 그 큰 스파이크는 다른 요청들이 무언가(아마도 공유 락일 가능성이 높습니다)를 기다리고 있음을 나타냅니다. 아마도 메가토픽(megatopic) 게시글 때문일 것입니다.
가능하다면 PostgreSQL 사용량 지표도 함께 확인해 주시면 유용할 것입니다.
메가토픽은 취약한 부분입니다. Improving Instance Performance (Megatopics, Database Size and Extreme Load) 를 참고하세요.
이들을 분리하거나 채팅을 사용하는 것을 고려해 보세요 (8,900개의 답변을 가진 가장 큰 메가토픽이 명시적으로 채팅방임을 확인했습니다).
우리 커뮤니티의 토론 문화는 메가토픽(megatopics)이며, 이는 디스코urses를 사용하기 전에 이미 형성되었습니다. 또한 채팅에는 흐림 스포일러와 숨겨진 세부 정보 기능이 부족합니다.
어떻게 하면 되는지 알려주세요
저희는 https://github.com/prometheus-community/postgres_exporter를 사용하고 있습니다. 다만, 메타에서 설정 관련 가이드가 있는지 확실하지 않습니다.
하지만 이미 Prometheus를 설정해 두신 것으로 보아, 관련 작업을 잘 알고 계신 것 같습니다.
현재 서버 RAM은 16/32GB, UNICORN_WORKERS: 12, db_shared_buffers: "4096MB"입니다.
여전히 사용 가능한 RAM이 남아 있고 웹 요청이 일부 대기 중이었기 때문에 UNICORN_WORKERS를 24로 늘렸습니다. 오늘 오후에 서버가 갑자기 종료되었고, 재시작 직후 사용자가 대거 몰렸습니다. 이로 인해 활성 웹 요청 수는 매우 낮아졌고 대기 중인 요청 수는 크게 증가했습니다. 며칠 전에는 24개의 UNICORN_WORKERS가 150개 이상의 활성 웹 요청을 처리할 수 있었지만, 오늘 오후에는 활성 웹 요청이 30개에 불과했습니다. 이는 도메인을 방금 변경했기 때문이며, sidekiq를 통해 많은 게시글이 재처리(rebake)되고 있습니다. 이로 인해 서버에 큰 부하가 걸렸습니다. 어떻게 해야 할까요?










