CPU 사용량이 85% 수준으로 높은 경우가 꽤 자주 발생합니다:
이전에는 unicorn.conf.r로 표시되었습니다:
이것이 UNICORN_WORKERS 값이 너무 높거나 낮게 설정되어 있음을 나타내는 것일 수 있나요?
서버는 64GB RAM(보통 40GB 정도가 비어 있음)과 6코어를 갖추고 있으며, 서버에는 UNICORN_WORKERS: 8로 설정된 4개의 Discourse 인스턴스가 있습니다.
원인이 무엇인지 또는 무엇을 시도해 볼 수 있는지에 대한 아이디어나 팁이 있을까요? (포럼 중 하나는 읽기 전용 모드로 설정되어 있고 트래픽이 많지 않은데, 워커 수를 줄이는 것이 좋을까요?)
잘 모르겠지만, 코어가 제공할 수 있는 것보다 워커를 훨씬 많이 사용하고 있는 거 아닌가요?
네. 유니콘 워커의 수를 줄이는 것도 제안합니다:
유니콘 워커 수를 줄이는 것을 시도해 볼 수 있습니다.
답변 주신 모든 분들께 감사드립니다 - 어디서 읽었는지는 기억이 나지 않지만, 항상 코어당 워커를 2개씩 설정해야 한다고 생각했습니다. 이제 포럼별로 워커 수를 줄이고, 가장 바쁜 포럼에는 더 많이, 덜 바쁜 포럼에는 적게 배정했습니다. 앞으로 일주일 동안 상황을 모니터링한 후, 도움이 되지 않았다면 다시 보고하겠습니다.
수정: 아마 여기에서 읽은 것 같습니다.
귀하의 경우 코어당 워커 2개를 할당하는 것이 아닙니다. 코어가 6개이므로 워커는 12개여야 하지만, 8개의 워커를 사용하는 인스턴스가 4개 있으므로 총 32개입니다.
네… 워커의 총 수가 코어 수의 2배를 넘지 않도록 조정했습니다. 하지만 여전히 궁금한 점이 있습니다. 제가 말씀드린 내용과 Nate의 게시글에서 Jeff가 인용한 ‘코어당 1워커’ 중 어떤 것이 정확하고 표준적인 조언일까요?
제 실험 결과에 따르면, 코어당 1워커를 설정하면 서버 부하가 낮아지지만 타임아웃이 더 자주 발생했습니다. 반면 워커 수를 늘리면 성능이 좋아지지만 부하도 높아지는데(제 서버에서는 여전히 허용 가능한 범위 내입니다).
오늘의 신규 설치에서 스케일링을 담당하는 discourse-setup을 확인해 보세요:
# UNICORN_WORKERS: 2GB 이하인 경우 2 * GB, 아니면 2 * CPU, 최대 8
if [ "$avail_gb" -le "2" ]
then
unicorn_workers=$(( 2 * $avail_gb ))
else
unicorn_workers=$(( 2 * $avail_cores ))
fi
unicorn_workers=$(( unicorn_workers < 8 ? unicorn_workers : 8 ))
2GB 이상의 RAM을 가진 시스템에서 기본값인 두 번째 문장, 즉 사용 가능한 코어 수의 두 배를 사용하는 로직입니다. 귀하의 문제는 discourse의 문제라기보다는 인스턴스(호스트 리소스) 간의 경쟁으로 인해 발생하는 것으로 보입니다.
저도 마지막 업그레이드 이후로 동일한 현상을 겪고 있습니다. 업그레이드는 원포스터(OP)가 글을 올린 지 하루 뒤에 진행했으므로, 이는 유니콘(unicorn) 워커 수와 무관할 것으로 생각합니다. unicorn.conf.r* 프로세스가 의심스러운데, 해당 용어에 대한 검색 결과 중 이 주제의 원포스트가 전 세계적으로 유일한 결과이기 때문입니다. 정상적으로는 unicorn.conf.rb가 더 일반적이어야 합니다.
증가는 정확히 4일 전인 제 마지막 업그레이드 시점에 발생했습니다. 참고로 OP는 5일 전에 글을 올렸습니다. Discourse에서 무언가 변경된 것이 분명합니다.
저는 수년간 동일한 인스턴스에서 동일한 수의 유니콘 워커를 사용해 왔으며, 아무것도 변경하지 않았습니다. 단지 3.4.0.beta4-dev로 재빌드했을 뿐입니다.
참고로, sidekiq에는 장기 실행 중이거나 실패한 작업이 없습니다.
최신 Discourse로 업그레이드한 후 더 이상 unicorn.conf.r*를 볼 수 없습니다. (이제 CPU 사용량이 80% 수준에 도달하는 프로세스는 모두 ruby로 표시되며, 발생 빈도는 이전보다 낮아 보입니다.) 로드 평균은 이전과 비슷하지만, 워커 수를 조정했을 때보다는 낮습니다.
최신 버전으로 업그레이드하셨나요? 어떤 하드웨어를 사용 중이며, 포럼의 트래픽은 얼마나 활발한가요?
마크, 우리의 상황이 관련이 있는지 확신하지 못합니다. 제 경우 스티븐이 말한 부분이 큰 역할을 한 것 같습니다:
최근 두 개의 다른 인스턴스를 동일한 서버로 옮겼는데, 이전에 코어가 더 많았던 서버를 사용했을 때 unicorn 워커가 8로 설정되어 있었다는 사실을 실제로 잊고 있었습니다(하지만 그 서버는 자체적인 문제가 있어 전체적으로 더 나은 성능을 발휘하는 코어가 적은 Xeon으로 다시 이전했습니다).
결국 이 서버에서 unicorn 워커를 줄이면 부하가 감소하지만 타임아웃이 발생하기 시작했고, 워커를 늘리면 타임아웃은 사라지지만 부하가 높아졌습니다 - 그래도 여전히 허용 가능한 범위 내였습니다. 워커를 더 늘려도 증가한 부하를 처리할 수 있다고 생각하지만, 현재 설정은 당분간 좋은 상태입니다.
그럼에도 불구하고, 인스턴스를 동일한 서버로 옮긴 후 예상했던 범위 내에서 실행되었습니다(부하가 증가했지만 상당한 수준은 아니었으며) 업데이트 후 부하가 높아진 느낌이 들었습니다… 하지만 이를 확신할 수는 없으며, Discourse가 기능을 추가하면서 때때로 더 강력한 하드웨어가 필요하거나 때로는 ‘느리게’ 느껴질 수 있다는 점을 염두에 두어야 합니다(구버전의 Discourse 인스턴스를 사용했을 때 훨씬 더 반응이 빠르다는 느낌을 받았지만 - 물론 새 버전의 모든 기능을 갖추고 있지는 않았습니다).
또한, 최신 Discourse 업데이트(PG 15) 이후 부하가 실제로 약간 감소한 것 같습니다.
마크에게 무엇을 제안해야 할지 모르겠습니다 - 워커와 다른 설정들도 조정해 보는 건 어떨까요? 예를 들어 db_shared_buffers나 db_work_mem 같은 것들요. "업데이트 후 CPU 사용량 높음 - 제 인스턴스가 성능 튜닝이 필요한가요?"와 같은 제목으로 전용 스레드를 시작해 보는 것도 좋을 것 같습니다. 또는 그런 식으로요 
결국 제 문제는 유니콘 워커가 아니었던 것 같습니다. @LotusJeff의 스레드 이후 @sam이 업데이트를 진행한 후, 서버 부하가 이전 수준(이전 피크치의 절반 미만)으로 돌아왔습니다…
이 방법으로 내 문제도 해결되었습니다.
최근 같은 서버에 있는 다른 두 포럼을 이전한 뒤로 서버 상태를 계속 주시하고 있었기 때문에, 그렇지 않았다면 이 문제를 발견하지 못했을 수도 있습니다. 이런 문제가 실제로 얼마나 많은 사용자에게 영향을 미쳤는지, 그리고 그중 몇 명이나 이를 인지하지 못하고 있는지 궁금합니다.
Discourse 팀은 이러한 문제를 감지하고 알리는 조치를 마련해 두었나요? 예를 들어, 관리자(Admin)가 특정 주제에 대해 설정할 수 있는 자원봉사 프로그램 같은 것 말입니다. “업그레이드 전/후 XX시간/일/주 동안 서버 부하를 Discourse로 전송” 같은 방식으로요. 아니면, 더 좋다면 서버 부하를 로컬에서 추적한 뒤 업그레이드 후 부하가 증가하는 것을 감지하면 관리자에게 알림을 보내는 방식도 좋습니다. 필요하면 여기서 공유할 수도 있겠죠.
아마 그 영향은 눈치채지 못했을 겁니다. 하지만 약 2주 전에 Discourse로 마이그레이션을 완료했기 때문에 서버를 세밀하게 모니터링하고 있습니다. 마이그레이션 이후 다양한 검증 작업(백업 실행 등)을 수행 중입니다. 몇 달이 지나면 그 영향은 절대 알아차리지 못했을 것입니다.
Discourse 측에서 매일 부하 테스트를 수행하고 있기를 바랍니다. 과거 제 경험상, 커밋된 코드로 매일 서버를 재빌드하는 시스템이 있었습니다. 이 시스템은 하루 종일 시뮬레이션된 사용자가 서버를 사용하도록 설계되어 있었습니다. 사용자 관점과 서버 관점 모두에서 주요 성능 지표를 측정했습니다. 이를 통해 메모리 누수, 비효율적인 코드, UX의 예상치 못한 변경 사항을 능동적으로 포착할 수 있었습니다.
아직도 Sam과 팀에 감사의 뜻을 전하고 싶습니다. phpBB의 세계에서 이런 문제가 해결되고 개선되려면 수십 년이 걸렸을 텐데, 빠른 대응은 정말 훌륭했습니다. (시드니 시간과 비교했을 때, 중부 시간(Central Time)으로 새벽 2시까지 깨어 있어야 했다는 점을 감안하더라도요.)
