100GB 이상 데이터베이스에서 프로필 로딩이 느립니다

이 게시물에 대한 후속 사항입니다: Slow Page Loads on User Profiles

해당 변경 사항이 배포된 후 이제 다시 Discourse로의 가져오기를 테스트하고 있으며, 프로필 로딩이 개선되었습니다(특히 데이터가 캐시에 저장된 후의 초기 로딩 이후). 그러나 일부 프로필은 여전히 5~10초가 걸립니다. 여기에 도움이 될 다른 조치가 있을까요? 문제의 원인인 쿼리는 다음과 같습니다:

2개의 좋아요

디스코urse를 어떻게 설치하셨나요?

1개의 좋아요

설정에 따라 Docker 컨테이너를 설치하세요.

1개의 좋아요

RAM 용량은 얼마인가요? 데이터베이스 크기는 얼마나 되나요?

1개의 좋아요

이 VM은 8코어와 32GB의 RAM을 갖추고 있습니다. 데이터베이스는 약 40GB 정도일 것 같지만, 현재로서는 100% 확신하지 못합니다.

1개의 좋아요

프로필 페이지가 느리게 로드되는 문제가 여전히 발생하는지 확인해 주세요.

  • 로그인하지 않은 상태(익명 사용자)에서 사용자 프로필 페이지를 볼 때?

  • 일반 사용자의 프로필 페이지와 스태프 사용자의 프로필 페이지를 비교해 볼 때?

2개의 좋아요

네, 두 가지 모두 그렇습니다. 일반 사용자로 테스트한 뒤 로그아웃했는데, 동작이 대략 비슷하게 나타났습니다.

내보내기 및 복원도 시도해 보았지만(관련 링크: Restore Failing - Check Free Disk Space) 동작이 변하지 않았습니다. 또한 이러한 프로필 페이지를 열 때에도 몇 초간 페이지 로딩을 시도한 후 오류가 발생하는 경우가 잦다는 점도 참고할 가치가 있습니다.

복원 이후 데이터베이스 크기는 현재 104GB입니다.

해당 토론은 주로 해당 라우트에서 발생하던 여러 N+1 쿼리 문제에 관한 것이었으며, 현재 모두 수정되었습니다.

프로필 페이지는 사용자의 매우 개인화되고 완전한 요약을 출력하기 때문에 일부 무거운 쿼리가 포함되어 있습니다. 그러나 합리적인 크기의 데이터베이스라면 500ms 이내에 렌더링할 수 있어야 합니다.

작은 VM에 대해선 상당히 큰 데이터베이스 용량입니다. 모든 것을 같은 VM(웹+DB+Redis)에서 실행하고 계신가요?

최신 PostgreSQL 13을 사용하고 계신가요? PostgreSQL 13 업데이트에 설명된 선택적 성능 작업인 vacuum과 reindex를 실행해 보실 수 있나요?

3개의 좋아요

문제가 있는 사용자는 게시물이 많은 사용자들입니다. 게시물 수가 적은 사용자의 프로필 페이지는 예상대로 즉시 로드됩니다.

여기서 제 기대치를 조정해야 할 수도 있겠습니다. 8코어와 32GB RAM은 Discourse에 대해 작은 규모로 간주됩니까? (네, 단일 컨테이너로 설치되어 있습니다.) 현재 소프트웨어에서는 2코어와 8GB RAM으로 이 보드를 쉽게 운영하고 있습니다.

데이터베이스의 경우, 새로 구축된 컨테이너이므로 13.1에서 시작되었습니다. 복원 직후에 vacuum과 reindex가 필요합니까?

1개의 좋아요

해당 크기의 데이터베이스의 경우 vacuum은 확실히 권장됩니다.

3개의 좋아요

글을 올린 직후 이 작업을 시작했습니다. 비어 처리(vacuum)는 매우 빠르게 완료되었지만, 재인덱싱(reindex)은 시작 후 24시간이 지났는데도 아직 진행 중입니다. 이런 상황이 정상인가요? 이 작업은 보통 얼마나 걸리나요? 어떤 리소스(있다면)가 병목 현상을 일으키고 있는지 어떻게 확인할 수 있을까요? 대부분의 시간 동안 postmaster 프로세스가 코어 2~4개 이상을 사용하지 않는 것으로 보이고, 사용 가능한 RAM도 충분해 보입니다.

1개의 좋아요

재인덱싱이 여전히 진행 중이라는 소식을 전하게 되어 안타깝습니다.

@Falco @codinghorror @pfaffman

@Ghan과 저는 지난 1년 동안 커뮤니티 가져오기(import) 기능이 정상적으로 작동하도록 완벽하게 다듬어 왔습니다. 그런데 제 머릿속에 떠오르는 질문이 있습니다. 2,500만 개 이상의 게시물을 가진 커뮤니티를 가져올 때 고려해야 할 다른 사항이 있을까요?

Discourse에 그 정도로 큰 규모의 커뮤니티가 있을까요?

공개된 고객 목록을 살펴본 결과, 제가 볼 수 있는 범위 내에서는 우리 규모에 근접한 고객이 아무도 없었습니다. 다만 제가 볼 수 없는 수천, 혹은 수만 명의 추가 고객이 있을 수도 있겠다는 생각은 듭니다. 우리는 가져오기를 성공적으로 완료했으며, 우리 측에서는 정상적으로 작동하고 있습니다. 하지만 게시물 수가 많은 계정의 프로필 로딩 문제와 이번 재인덱싱(re-indexing) 문제처럼 여러 가지 장애물에 계속 부딪히고 있습니다.

이 전이를 원활하게 진행할 수 있도록 조언을 구할 수 있을까요?

1개의 좋아요

다른 게시물에서 db:stats rake 명령어를 찾았습니다.
재인덱싱이 아직 진행 중이라 이 숫자가 100% 최종 수치인지는 확신할 수 없습니다.

3개의 좋아요

네, 다른 주제에서 말씀드린 것처럼 1GB 데이터베이스를 가진 인스턴스와 500GB 데이터베이스를 가진 인스턴스가 있습니다. 하지만 해당 인스턴스는 완전히 다른 크기의 VM에서 실행되고 있습니다.

서버의 디스크 성능은 어떻게 되나요? 구식 회전 하드 디스크를 사용하나요?

2개의 좋아요

호스트 서버에는 ZFS 미러링으로 구성된 듀얼 1.2TB Intel P3600 NVMe SSD가 설치되어 있습니다.

2개의 좋아요

다음으로 확인할 것은 PostgreSQL 튜닝입니다. app.yml에서 기본값을 사용 중이시죠?

1개의 좋아요

네. 런서가 호스트 머신에서 확인한 리소스에 따라 일부 값을 자동으로 설정하는지, 아니면 튜닝을 위한 권장 가이드라인이 따로 있는지 확실하지 않았습니다. 데이터베이스 튜닝에 대한 가이드가 어딘가에 있나요?

app.yml 파일에 몇 가지 주석이 있지만, 이 설정은 실제로는 더 작은 규모의 셀프호스팅 사이트에 최적화되어 있습니다. 해당 설정 값을 높여야 할 가능성이 높습니다(정확한 이름은 기억나지 않습니다). 더 자세한 정보는 일반적인 PostgreSQL 관련 자료를 참고해 보시기 바랍니다.

Discourse가 사용자의 커뮤니티 규모를 처리하지 못한다는 뜻은 아닙니다. 다만 작은 규모로 운영할 때와는 다르며, 조금 더 어렵습니다.

3개의 좋아요

감사합니다, 꼭 확인해 보겠습니다. Postgres는 잘 모르지만, 수년간 MySQL을 운영해 온 경험에서 동일한 원칙들이 적용되길 바랍니다.

그렇습니다. 어떤 변경 사항이 필요한지에 대해 방향성이 잡히면, 이후 진행이 훨씬 수월해질 것 같습니다.

3개의 좋아요