안녕하세요,
CentOS 7 서버를 2.2.2에서 2.7.0.beta4로 업그레이드한 이후로 페이지 로딩 지연 문제가 발생하고 있습니다. 특히 데이터베이스나 이미지 콘텐츠가 포함된 페이지에서 심하며, 사용이 불가능할 정도입니다.
이와 관련하여 조언을 주시면 감사하겠습니다.
지난 몇 년간 여러 일이 있었습니다. 모든 이미지를 처리해야 하는 버그 수정이 있었거든요. 서버가 해당 작업을 처리하느라 과부하 상태일 것 같습니다. /sidekiq에서 큐 상태를 확인할 수 있습니다.
데이터베이스 크기는 얼마나 되나요? 이미지는 몇 개나 있나요? Sidekiq에서는 어떤 상태가 표시되나요? SSD를 사용 중이시죠?
VM 기반 서버라서 SSD인지 아닌지 정확히 알 수 없습니다.
이 배포는 제가 수행한 것이 아니라서 sidekiq에 접근하는 방법을 모르겠습니다.
설치 방법이 어떻게 되었는지 아세요? 표준 설치가 아닌 것 같습니다 (관리자라면 표준 설치인 경우 /sidekiq에 접근할 수 있었을 테니까요).
가장 좋은 방법은 성능이 저하된 이유를 조사하는 것입니다. 지난 몇 년간 이미지 최적화, 리베이킹(Rebaking) 등 많은 수의 백그라운드 작업이 추가되었는데, 현재 이 작업들이 실행 중이어서 서버 리소스를 점유하고 있을 가능성이 큽니다. 해당 작업들이 완료되면 성능이 개선되어야 합니다.
/sidekiq에 접근(관리자 계정으로!)하여 현재 실행 중인 작업이 무엇인지 확인하는 것이 훌륭한 첫걸음이 될 것입니다.
서버에서 확인되는 동작은, 게시물을 열어서 목록에 표시되도록 시도해도 여전히 빈 큐가 표시되는 것입니다. 또한 게시물이 로드되는 동안 사이드킥(Sidekiq) 포털도 멈추고, 게시물이 완전히 로드된 후에야 새로고침이 됩니다.
그리고 게시물이 로드된 후에도 다시 빈 큐가 표시됩니다. 도움이나 제안이 있다면 매우 감사하겠습니다.
큐가 비어 있으면 백그라운드 작업이 너무 많이 실행되고 있다는 문제는 아닙니다. 따라서 다른 원인이 있을 것입니다.
플러그인이 있나요? 많은 수의 API 호출을 생성하는 테마 구성 요소가 있나요?
위에 다른 질문들을 몇 가지 더 드렸습니다.
데이터베이스 크기는 얼마인가요?
이미지 수는 몇 개인가요?
많은 수의 API 호출을 발생시키는 테마 컴포넌트가 있나요?
주어진 Docker 기반 설정에서 위 정보를 어떻게 확인할 수 있는지 알려 주실 수 있나요? 마지막 백업 파일이 135MB라는 것은 알고 있습니다.
플러그인 관련해서는, 다음 플러그인 목록을 사용하고 있습니다:
- git clone https://github.com/discourse/docker_manager.git
- git clone https://github.com/jonmbake/discourse-ldap-auth.git
- git clone https://github.com/discourse/discourse-math
- git clone https://github.com/discourse/discourse-chat-integration.git
- git clone https://github.com/discourse/discourse-voting.git
- git clone https://github.com/unfoldingWord-dev/discourse-mermaid.git
- git clone https://github.com/discourse/discourse-solved.git
- git clone https://github.com/discourse/discourse-assign.git
- git clone https://github.com/discourse/discourse-knowledge-explorer.git
- git clone https://github.com/discourse/discourse-cakeday.git
mermaid 플러그인을 제거하는 것을 권장합니다.
게시물과 사용자는 몇 명이나 있나요? 트래픽은 어떤가요?
RAM 용량은 얼마나 되나요?
2GB 디지털 오션 드롭렛이면 충분할 것 같습니다. 하나를 설정해 보고 작동하는지 확인해 보세요.
서버에 다른 문제가 있는 것일 수도 있습니다. 최신 버전으로 업데이트되어 있나요? 최근에 재부팅을 해 보셨나요?
네, 그 부분은 제거하겠습니다.
현재 게시글이 약 4,000개이고 사용자는 약 350명입니다.
동시에 로그인한 평균 사용자 수는 많지 않아서, 평균적으로 최대 5~10명 정도입니다.
이 서버는 최근에 세팅되었으며, 8GB RAM과 10GB의 스왑 공간을 공유하고 있습니다. 현재까지 가동된 지 13일째입니다. 하지만 성능 문제는 재부팅이나 가동 시간과 무관하게 발생하고 있습니다.
설정에 분명 문제가 있습니다. 이 하드웨어를 사용한다면 훨씬 더 나은 성능을 기대할 수 있어야 합니다.
Postgres에서 명시적인 VACUUM을 실행해 보세요. 올인원 컨테이너 설치를 사용하고 있다면:
# docker exec -it -u postgres app psql discourse
psql (13.1 (Debian 13.1-1.pgdg100+1))
Type "help" for help.
discourse=# VACUUM ANALYZE;
VACUUM
app.yml에서 유니콘(unicorn) 워커를 몇 개로 설정해 두셨나요?
env 섹션에 다음 내용을 추가하면 Discourse가 응답에 추가 성능 헤더를 설정하도록 할 수 있습니다:
DISCOURSE_ENABLE_PERFORMANCE_HTTP_HEADERS: true
기회를 aproveitando, 이 게시물을 참고하여 miniprofiler를 활성화할 수도 있습니다.
그 정도면 꽤 충분할 것입니다.
discourse-setup을 다시 실행하여 Discourse의 메모리 사용량을 조정하도록 제안받았는지, 아니면 서버에서 다른 작업에 사용되고 있는 자원들을 고려할 때 해당 기본값이 적절한지 기억이 나지 않습니다.
PG13 업그레이드 후 데이터베이스를 다시 인덱싱하지 않았다면, 해당 정보에 대해 PostgreSQL 13 업데이트를 참고해 보시기 바랍니다.
아 네, 테이블 통계 정보의 부족(VACUUM ANALYZE)이 여기서 가장 유력한 원인일 가능성이 높습니다.
VACUUM FULL VERBOSE;
REINDEX DATABASE discourse;
VACUUM VERBOSE ANALYZE;
cmd를 실행하고 env에 헤더도 설정했지만, 페이지 로딩 시간에는 큰 차이를 느끼지 못했습니다.
현재 8개의 unicorn을 실행 중입니다.
postgres에서 해당 명령어를 실행하셨죠?
네, 위 명령어를 실행하기 전에 docker exec -it -u postgres app psql discourse를 실행했습니다.
음, 정말 이상하네요. 다른 분들은 이런 문제를 겪지 않았거든요. 하드웨어는 충분해 보입니다. 제 추측으로는 리버스 프록시 관련 문제인 것 같네요. (혹시 그 머신에 다른 서비스도 돌리고 계신 건가요?)
네, 또 도커 기반 서비스입니다.
하지만 성능에 큰 부하를 주는 작업은 전혀 아니었습니다. 그랬다면 해당 머신의 성능 지표에 분명히 드러났을 테니까요.