좋은 스펙이네요! 특히 트래픽이 많은 사이트인가요?
리베이킹이 일어나지 않았다고 확신하시나요?
1분당 몇 장의 이미지가 게시되고 있나요?
썸네일 생성은 대부분 코어 코드에 해당하며, 필수적인 추가 이미지 처리가 필요합니다.
이러한 성격의 플러그인이나 테마 컴포넌트라면 모두 해당됩니다.
3개의 좋아요
플러그인을 약 24시간 동안 꺼뒀다가 다시 24시간 동안 켰습니다.
아래에는 다른 관리자로부터 받은 메모를 붙여넣었습니다.
플러그인이 예약된 작업(job)의 속도를 늦추고 있습니다.
큐에 있는 작업이 많을수록 CPU가 따라가지 못해 부하가 커집니다.
즉, 서버는 많은 트래픽을 감지하지만, 작업이 쌓이기 시작할 때까지는 일정한 것처럼 보입니다.
결국 CPU가 처리를 따라가지 못하면서, 밀린 작업을 처리하는 동안 사용량이 급격히 오르내립니다.
그래서 앞서 밀린 작업이 3000개 이상인 것을 본 것입니다.
정상적인 상황에서는 5개 이상의 작업이 쌓이는 일은 절대 없으며, 밀려서 처리되지 않을 작업이 없으므로 대부분 0개입니다.
첨부된 이미지는 현재 작업이 쌓이는 모습을 보여줍니다. 현재 밀린 작업이 30~35개 수준으로 유지되고 있습니다.
모든 작업은 사이드카(sidebar)의 마지막 게시물에서 새로 생성된 것입니다.
아직 이유는 모르겠지만, 이는 플러그인이 켜져 있을 때만 발생합니다.
CPU 리소스의 지난 1시간 데이터
지난 24시간 데이터. 플러그인이 활성화된 대략적인 시점을 표시했습니다. (스파이크 이후의 상승 추이를 참조)
패턴이 24시간보다 길어지는 것처럼 보이지만, 플러그인은 대부분의 시간 동안 80~90% 이상의 전반적인 리소스 사용률을 유발합니다.
플러그인을 끄면, 향후 24시간 동안 서버 평균 사용률이 60~75%로 떨어지고 작업이 쌓이지 않는 것을 확인할 수 있을 것입니다.
또한 원할 때 app.yml을 수정하여 16개의 유니콘(unicorn) 워커를 설정했습니다. 재빌드할 때는 플러그인을 비활성화하고 16개의 유니콘 워커를 사용하는 것이 좋다고 생각합니다. 해당 기간 동안 서버 성능을 관찰한 후, 최적이라고 판단되는 워커 수로 조정하면 됩니다.
지난 7일 데이터
빨간색 = 활성화
파란색 = 비활성화
플러그인을 다시 켜자 CPU가 급등했습니다. 작업(job) 부분이 주요 원인이라는 데 대해서는 확신이 적어졌습니다. 유니콘 워커가 많아지면 작업 수가 증가하는 것을 확인했습니다. 이 수치는 무관하다고 생각합니다.
다만, 플러그인이 리소스를 점유하는 문제는 여전히 관찰됩니다.
아직 100% 확신은 없지만, 플러그인이 문제라는 데에는 매우 확신이 있습니다.
플러그인 + 16개 워커: 서버가 막힘(pinning)
16개 워커 + 플러그인 없음: 정상 작동
플러그인 + 8개 워커: 느리지만 작동은 함
플러그인을 껐之后的 그래프
1개의 좋아요
안녕하세요,
그 메모를 작성한 다른 관리자입니다.
더 이상 해당 작업(jobs)이 문제의 일부라고 보지 않습니다.
불행히도 Discourse의 내부 구조에 대해 잘 알지 못해 원인이 무엇일지 파악하기 어렵습니다. 현재 제가 확인하는 내용만 알고 있을 뿐입니다.
요약하자면, 8개 워커로 활성화되어 있을 때 사이트가 전반적으로 느리고, 16개 워커로 올리면 거의 다운되는 수준입니다.
플러그인을 비활성화하면 사이트가 완벽하게 정상 작동하며, 워커 수가 충분할 경우 매우 빠릅니다.
이로 인해 플러그인 내에서 리소스 사용량 증가나 I/O 또는 비동기 작업의 병목 현상 등으로 사이트 성능을 저하시키는 요소가 있는 것으로 추정됩니다.
1개의 좋아요
sidekiq 큐를 확인해 보시겠어요? 대기 중인 작업이 많이 보이며, 작업 이름은 무엇인가요?
이미지 처리가 모두 완료되면 자연스럽게 해결될 섬네일 생성 작업의 백로그일 뿐이라고 확신합니다.
이것은 핵심 프로세스입니다.
추가 기능이 필요하지 않고 Theme Component만 사용하신다면 sidecar 플러그인을 안전하게 제거할 수 있습니다.
sidecar 플러그인이 비활성화된 상태에서 Theme Component만 활성화되었을 때에도 문제가 계속 발생하는지 확인해 주시겠어요?
sidecar 플러그인을 설치한 적이 없다면 문제는 코어에 있을 수밖에 없습니다.
분석에 도움이 필요하시면 Pavilion을 고용할 수 있습니다.
이 문제에 대한 독립적인 보고를 환영합니다.
4개의 좋아요
확인해 드리고 싶은 점은, 주제 목록 썸네일 테마 구성 요소를 활성화하면 고 CPU 사용률의 이미지 리사이즈 작업이 증가하는 것이 예상된다는 것입니다 
. Core는 주제 목록에서 특정 주제를 처음 보는 사용자를 위해 썸네일을 ‘요청 시(on demand)’ 생성합니다.
@merefield가 언급했듯이, 자주 목록에 표시되는 주제에 대한 모든 썸네일이 생성되면 상황이 안정될 것입니다.
워커 수를 늘리는 것은 좋은 생각이 아닐 수 있습니다 - CPU 자원이 제한된 기계에서 병렬로 더 많은 작업을 시도하면 증상이 더 악화될 수 있습니다. 워커 수를 정상적으로 유지하여 작업이 대기열에 쌓이고 기계가 과부하되지 않도록 처리되는 것이 좋습니다.
Sidekiq UI에서는 "Busy(실행 중)"와 “Queued(대기 중)” 탭을 확인하는 것이 좋습니다. “Scheduled(예약됨)” 작업은 미래의 특정 시간에 예약된 작업이므로 성능 문제를 일으킬 가능성이 매우 낮습니다.
4개의 좋아요
1개의 좋아요
많은 “전체 변환” 테마는 지원되지 않습니다. FKB Pro가 이 컴포넌트와 충돌하는 자체 오버라이드를 가지고 있을 것으로 추정됩니다. 이 시나리오는 지원할 수 없습니다.
이 테마 컴포넌트는 모든 기능을 다루지 않는 테마 내에서 빌딩 블록으로 사용되도록 설계되었습니다.
토ピック 목록 미리보기가 포함된 우측 사이드바를 원하신다면 Right Side Blocks를 함께 사용해 보세요.
3개의 좋아요
실험적 기능이 추가되었습니다:
1개의 좋아요
이제 꽤 잘 작동하고 있으며, 아직 설정 옵션 뒤에 숨겨져 있습니다:
이것은 폭에 반응하여, 목록 영역이 충분히 넓을 때만 타일(메이슨리) 모드에서 표시됩니다.
데모: https://www.starzen.space/
참고: 우측 하단의 과도한 패딩은 성능상의 이유(매우 빠르니까요!)로 가장 가까운 그리드 행에 렌더링하는 메이슨리 렌더러로 인해 발생하는 알려진 필수 문제입니다. CSS 그리드에 네이티브 메이슨리가 구현되는 그날(!)이 오면, 더 보기 좋게 리팩토링할 예정입니다.
참고 2: 스크린샷에는 Discourse Bars 테마 컴포넌트의 일부 컨트롤(사이드바는 숨겨진 상태)도 포함되어 있습니다. Topic List Previews는 Discourse Bars와 매우 잘 어울립니다.
1개의 좋아요
홈페이지에 YouTube용 이미지가 표시됩니다.
Twitter용으로도 사용할 수 있을까요?
2개의 좋아요
유튜브로만 제한되는 것은 아닙니다.
썸네일 자체를 그대로 노출합니다. 트위터 임베드가 썸네일을 생성한다면, 그렇습니다.
3개의 좋아요
이 설정에서 라우트를 제거하세요:
그렇지 않으면 "Tiles"로 표시됩니다. “Tiles” 형식으로 라우트를 전혀 표시하지 않으려면 이 모든 줄을 제거해야 하지만, 모바일에서 Tiles를 사용하는 것을 고려해 볼 수도 있습니다(이 경우 *-mobile이 포함된 항목은 유지하세요).
2개의 좋아요
지금은 완벽해요. 감사합니다 
2개의 좋아요
동봉된 사이드카 플러그인(OP에 나열되어 있음)에 해당 설정이 있습니다:
하지만 플러그인이 없다면 네이티브 설정을 시도해 볼 수 있습니다:
오래전에 확인한 이후로는 다시 살펴본 적이 없습니다! 
1개의 좋아요
말씀하신 설정을 조정해 보고 있지만, 작동하지 않습니다.
흥미로운 점은 한 주제에 대한 요약이 너무 적고, 다른 주제에 대해서는 너무 많다는 것입니다.
문자 수는 특정 한도 내에서만 허용됩니다.
1개의 좋아요
사이드카 플러그인을 설치하고 해당 설정을 사용하세요.
2개의 좋아요
토픽 요약을 다시 생성하려면 post rebake를 실행해야 할 것 같습니다.
1개의 좋아요