A atualização leva cerca de 20 minutos e a atualização de progresso quebra (temporariamente) na etapa multisite:migrate

Suporte
1

Acabei de fazer a atualização semanal do nosso site Discourse e descobri que, em vez dos 1-2 minutos habituais, desta vez foram necessários cerca de 20 minutos. Além disso, a atualização de progresso foi temporariamente interrompida com erros de timeout no console do Chrome na etapa $ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate (captura de tela abaixo).

Pude ver no servidor que algo estava acontecendo (carga no postmaster e ocasionalmente no ruby), e eventualmente as atualizações de progresso se recuperaram, mas, no geral, parece haver um problema com as migrações atuais.

Pelos logs de atualização, parece que a migração responsável pelo longo tempo de execução foi DropTrgmIndexesOnUsers. Incluí a parte respectiva do log diretamente nesta postagem abaixo (o log completo está anexado como um arquivo de texto, caso seja necessário para análise posterior).

image
image947×718 61.2 KB

********************************************************
*** Por favor, seja paciente, os próximos passos podem demorar ***
********************************************************
...
$ LOAD_PLUGINS=0 bundle exec rake plugin:pull_compatible_all
discourse-bbcode já está na versão compatível mais recente
docker_manager já está na versão compatível mais recente
$ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate
O migrador multisite está em execução usando 1 threads

Migrando padrão
== 20240912061702 DropUserSearchSimilarResultsSiteSetting: migrando ==========
-- execute("DELETE FROM site_settings WHERE name = 'user_search_similar_results';\n")
   -> 0.0006s
== 20240912061702 DropUserSearchSimilarResultsSiteSetting: migrado (0.0015s) ==

== 20240912061806 DropTrgmIndexesOnUsers: migrando ===========================
-- 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: migrado (1290.7169s) ===============

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

Populando padrão
*** Empacotando assets. Isso levará um tempo *** 
$ bundle exec rake themes:update assets:precompile
Construindo
Ambiente: production
construindo...
...

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

3

Não tenho certeza se há algo que possamos fazer agora.

Precisamos remover o índice e, se o seu fórum estiver muito ocupado na época, pode levar um tempo.

Assume-se que tudo está bem agora?

4

Sim, as coisas voltaram ao normal agora, então não há problema imediato.

O principal motivo pelo qual relatei isso aqui foi que o indicador de progresso estava temporariamente quebrado, e talvez isso possa levar as pessoas a acreditar que a atualização travou (não tenho certeza do que realmente pode ser feito aqui).

No entanto, este não foi o caso. O servidor é um servidor de teste (precisamos fazer bastante preparação) e eu geralmente executo as atualizações após a meia-noite, então acho que provavelmente fui o único usuário.

Portanto, a outra pergunta que me ocorreu depois é: o Discourse realmente requer um SSD para comunidades como a nossa (~6 mil usuários, ~2,5 milhões de posts)? Porque o servidor atual é decente (AMD Ryzen 5 3600, 64 GB de RAM), mas ele tem discos giratórios clássicos e, se isso for um problema, precisaremos mudar para um com SSDs antes de entrarmos em produção.

5

Remover esse índice em um servidor com apenas 6 mil usuários deve levar milissegundos, mesmo em um disco rígido mecânico; é um forte indicativo de que seu banco de dados está com poucos recursos.

6

Ok, obrigado! Eu não sabia que a otimização do banco de dados seria necessária (estamos usando a configuração de contêiner único) e não há muito mais rodando na máquina (Discourse, Mailcow, Traefik, Crowdsec). Mas vou dar uma olhada mais de perto.

Alguma dica sobre a documentação relevante a esse respeito? A única coisa que sei no momento é Configure Discourse Docker on servers with more RAM and CPU, e nosso db_shared_buffers já está em 4096MB.

7

Suspeito que isso ocorra porque não removemos o índice de forma concorrente.

Um DROP INDEX normal adquire um bloqueio ACCESS EXCLUSIVE na tabela, bloqueando outros acessos até que a remoção do índice possa ser concluída.

Isso deve ser corrigido em PERF: Update migration to drop index concurrently. by tgxworld · Pull Request #28955 · discourse/discourse · GitHub.

@schneeland Obrigado por dedicar seu tempo para relatar o problema :+1:

2 curtidas