업데이트에 약 20분이 걸리며 진행 상황이 multisite:migrate 단계에서 (일시적으로) 중단됩니다

Discourse 사이트의 주간 업데이트를 진행하던 중, 평소 1~2분 걸리던 작업이 이번에는 약 20분이 소요되는 것을 발견했습니다. 또한, $ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate 단계에서 Chrome 콘솔에 타임아웃 오류가 발생하여 진행 상태 업데이트가 일시적으로 중단되었습니다(아래 스크린샷 참조).

서버에서는 postmaster와 간헐적으로 ruby에 부하가 걸리는 것을 확인했으며, 결국 진행 상태 업데이트는 복구되었지만, 현재 마이그레이션에 문제가 있는 것으로 보입니다.

업데이트 로그를 확인한 결과, 긴 실행 시간을 유발한 마이그레이션은 DropTrgmIndexesOnUsers인 것으로 나타났습니다. 해당 로그의 관련 부분을 이 게시글 아래에 직접 포함했으며, 추가 분석이 필요한 경우를 대비해 전체 로그를 텍스트 파일로 첨부했습니다.

********************************************************
*** Please be patient, next steps might take a while ***
********************************************************
...
$ LOAD_PLUGINS=0 bundle exec rake plugin:pull_compatible_all
discourse-bbcode is already at latest compatible version
discourse-data-explorer is already at latest compatible version
docker_manager is already at latest compatible version
$ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate
Multisite migrator is running using 1 threads

Migrating default
== 20240912061702 DropUserSearchSimilarResultsSiteSetting: migrating ==========
-- execute("DELETE FROM site_settings WHERE name = 'user_search_similar_results';\n")
   -> 0.0006s
== 20240912061702 DropUserSearchSimilarResultsSiteSetting: migrated (0.0015s) =

== 20240912061806 DropTrgmIndexesOnUsers: migrating ===========================
-- execute("DROP INDEX IF EXISTS index_users_on_username_lower_trgm;\nDROP INDEX IF EXISTS index_users_on_name_trgm;\n")
   -> 1290.7163s
== 20240912061806 DropTrgmIndexesOnUsers: migrated (1290.7169s) ===============

== 20240912212253 IncreaseExternalAvatarUrlLimitTo2000: migrating =============
-- change_column(:single_sign_on_records, :external_avatar_url, :string, {:limit=>2000})
   -> 0.0011s
== 20240912212253 IncreaseExternalAvatarUrlLimitTo2000: migrated (0.0017s) ====

Seeding default
*** Bundling assets. This will take a while *** 
$ bundle exec rake themes:update assets:precompile
Building
Environment: production
building...
...

전체 로그: upgrade-log-2024-09-15.txt (124.7 KB)

지금 우리가 할 수 있는 일이 있는지 확신할 수 없습니다.

인덱스를 삭제해야 하는데, 해당 시점에 포럼이 매우 혼잡했다면 시간이 좀 걸릴 수 있습니다.

모든 문제가 해결된 것으로 봐도 될까요?

네, 지금은 다시 정상으로 돌아왔으므로 당장의 문제는 없습니다.

여기에 보고한 주된 이유는 진행 상황 표시줄이 일시적으로 고장 났기 때문이며, 이는 업데이트가 충돌한 것처럼 보이게 할 수 있는 요소입니다(여기서 실제로 할 수 있는 조치가 얼마나 될지는 잘 모르겠습니다).

하지만 이번 경우는 그렇지 않았습니다. 이 서버는 테스트 서버이며(상당한 사전 준비가 필요합니다) 저는 보통 자정 이후에 업데이트를 실행하므로, 아마도 제가 유일한 사용자였을 것입니다.

따라서 이후에 제 머릿속에 떠오른 다른 질문은 다음과 같습니다: 우리와 같은 커뮤니티(약 6,000명 사용자, 약 250만 개의 게시글)의 경우 Discourse가 실제로 SSD를 요구하나요? 현재 서버는 상당히 좋은 사양(AMD Ryzen 5 3600, 64GB RAM)이지만, 고전적인 회전 디스크를 사용하고 있습니다. 만약 이것이 문제가 된다면, 정식 운영을 시작하기 전에 SSD가 장착된 서버로 교체해야 할 것입니다.

유저가 단 6천 명뿐인 서버에서 해당 인덱스를 삭제하는 데는 스피닝 디스크를 사용하더라도 밀리초 단위로 완료되어야 합니다. 이는 데이터베이스가 리소스에 극도로 제한되어 있음을 강력하게 시사하는 신호입니다.

네, 감사합니다! DB 튜닝이 필요하다는 사실을 몰랐습니다(단일 컨테이너 구성을 사용 중이며, 해당 머신에는 Discourse, Mailcow, Traefik, Crowdsec 외에는 거의 다른 서비스가 실행되지 않습니다). 하지만 더 자세히 살펴보겠습니다.
이와 관련하여 관련 문서를 알려줄 수 있을까요? 현재 제가 아는 것은 Configure Discourse Docker on servers with more RAM and CPU 링크뿐이고, 저희 db_shared_buffers는 이미 4096MB로 설정되어 있습니다.

이 문제는 인덱스를 병렬로 삭제하지 않았기 때문일 것으로 추정됩니다.

일반적인 DROP INDEX는 테이블에 ACCESS EXCLUSIVE 잠금을 획득하여 인덱스 삭제가 완료될 때까지 다른 접근을 차단합니다.

이 문제는 PERF: Update migration to drop index concurrently. - Pull Request #28955 - discourse/discourse - GitHub 에서 수정되어야 합니다.

@schneeland 문제를 보고해 주셔서 감사합니다 :+1: