Обновление занимает ~20 минут, и прогресс-бар временно застревает на шаге multisite:migrate

Я только что выполнил еженедельное обновление нашего сайта на Discourse и обнаружил, что вместо обычных 1–2 минут на этот раз потребовалось около 20 минут. Кроме того, на этапе $ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate прогресс-обновления временно прервались из-за ошибок тайм-аута в консоли Chrome (скриншот ниже).

На сервере я видел, что какая-то активность происходила (нагрузка на postmaster и иногда на ruby), и в итоге обновления прогресса восстановились, но в целом кажется, что с текущими миграциями может быть проблема.

Судя по логам обновления, миграция, вызвавшая длительное выполнение, — это DropTrgmIndexesOnUsers. Соответствующую часть лога я привёл непосредственно в этом сообщении ниже (полный лог прикреплён в виде текстового файла на случай, если он понадобится для дальнейшего анализа).

********************************************************
*** Пожалуйста, будьте терпеливы, следующие шаги могут занять время ***
********************************************************
...
$ LOAD_PLUGINS=0 bundle exec rake plugin:pull_compatible_all
discourse-bbcode уже находится в последней совместимой версии
discourse-data-explorer уже находится в последней совместимой версии
docker_manager уже находится в последней совместимой версии
$ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate
Мульти-сайтовый мигратор запущен с использованием 1 потока

Миграция default
== 20240912061702 DropUserSearchSimilarResultsSiteSetting: начало миграции ==========
-- execute("DELETE FROM site_settings WHERE name = 'user_search_similar_results';\n")
   -> 0.0006s
== 20240912061702 DropUserSearchSimilarResultsSiteSetting: завершена (0.0015s) =

== 20240912061806 DropTrgmIndexesOnUsers: начало миграции ===========================
-- 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: завершена (1290.7169s) ===============

== 20240912212253 IncreaseExternalAvatarUrlLimitTo2000: начало миграции =============
-- change_column(:single_sign_on_records, :external_avatar_url, :string, {:limit=>2000})
   -> 0.0011s
== 20240912212253 IncreaseExternalAvatarUrlLimitTo2000: завершена (0.0017s) ====

Посев default
*** Сборка ассетов. Это займёт некоторое время *** 
$ bundle exec rake themes:update assets:precompile
Сборка
Окружение: production
сборка...
...

Полный лог: upgrade-log-2024-09-15.txt (124.7 КБ)

Я не уверен, что мы сейчас что-то можем сделать.

Нам нужно удалить индекс, и если ваш форум в этот момент был очень загружен, это может занять некоторое время.

Можно считать, что всё в порядке?

Да, всё вернулось в норму, так что срочных проблем нет.

Основная причина, по которой я сообщил об этом здесь, заключалась в том, что индикатор прогресса временно не работал, и это может заставить людей подумать, что обновление зависло (не уверен, насколько здесь вообще можно что-то сделать).

Однако в нашем случае это не так. Сервер является тестовым (нам нужно провести значительную подготовку), и я обычно запускаю обновления после полуночи, так что, вероятно, я был единственным пользователем.

Поэтому следующий вопрос, который у меня возник: действительно ли Discourse требует использования SSD для сообществ нашего масштаба (~6 тыс. пользователей, ~2,5 млн постов)? Текущий сервер довольно мощный (AMD Ryzen 5 3600, 64 ГБ ОЗУ), но в нём установлены обычные жёсткие диски. Если это станет проблемой, нам придётся перейти на сервер с SSD до запуска в эксплуатацию.

Удаление этого индекса на сервере всего с 6 тысячами пользователей должно занимать миллисекунды, даже на обычном жёстком диске; это верный признак того, что вашей базе данных не хватает ресурсов

Хорошо, спасибо! Я не знал, что потребуется настройка базы данных (мы используем одноконтейнерную конфигурацию), и на сервере запущено не так много других сервисов (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: