アップデートに約20分かかり、multisite:migrateのステップで進捗表示が一時的に壊れる

先週、Discourseサイトのアップデートを行ったところ、通常1〜2分で完了するはずの作業に今回は約20分かかりました。また、Chromeコンソールでタイムアウトエラーが発生し、$ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate のステップで進捗アップデートが一時的に失敗しました(スクリーンショットは下記参照)。

サーバー上では何かが進行している様子(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...
...

Full log: upgrade-log-2024-09-15.txt (124.7 KB)

もう何もできないと思います。

インデックスを削除する必要があり、フォーラムが非常に混雑していた場合、時間がかかることがあります。

すべて順調だと仮定しますか?

はい、今はすべて通常に戻ったので、差し迫った問題はありません。

ここに報告した主な理由は、進捗インジケーターが一時的に壊れていたことで、これによりアップデートがクラッシュしたと信じる人がいるかもしれないということです(ここで実際にできることはあまりないかもしれませんが)。

しかし、そうではありませんでした。サーバーはテストサーバーであり(かなりの準備が必要です)、通常は深夜以降にアップデートを実行するため、おそらく私だけがユーザーだったと思います。

その後、もう一つ思いついた質問は、Discourseは私たちのコミュニティ(約6,000人のユーザー、約250万件の投稿)のようなコミュニティでは、実質的にSSDを必要としますか?現在のサーバーはまともですが(AMD Ryzen 5 3600、64GB RAM)、従来の回転ディスクを備えており、それが問題であれば、本番稼働前にSSDを備えたものに切り替える必要があります。

6,000ユーザーしかいないサーバーでそのインデックスを削除しても、スピニングディスク上であってもミリ秒で完了するはずです。これは、データベースがリソース不足であるという強い兆候です。

わかりました、ありがとうございます!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. by tgxworld · Pull Request #28955 · discourse/discourse · GitHub で修正されるはずです。

@schneeland 問題を報告する時間を割いていただきありがとうございます :+1:

「いいね!」 2