### Author:  [@Wingtip](https://meta.discourse.org/u/Wingtip)
#### Post date: [21 Agosto , 2020 00:58 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/1 "2020-08-21T00:58:18Z")
Apenas um aviso para todos: não tentem essa atualização durante o horário de pico.
A atualização para a versão 2.6.0b2 está rodando no nosso servidor há mais de 40 minutos, quando normalmente leva apenas alguns minutos, geralmente terminando antes mesmo de você voltar a verificar. Fiquei preocupado que tivesse quebrado, mas ao acessar o PostgreSQL, vi uma atualização massiva em execução; parece que está alterando os dados de busca de postagens para mensagens privadas.
Espero que _não_ esteja quebrado. Acho que vou descobrir. _Realmente_ não quero matar o processo ou reiniciar o container no meio da atualização.
Consulta em execução:
```plaintext
postgres=# SELECT pid, age(clock_timestamp(), query_start), usename, query
FROM pg_stat_activity
WHERE query != '' AND query NOT ILIKE '%pg_stat_activity%'
ORDER BY query_start desc;
pid | age | usename | query
-------+-----------------+-----------+---------------------------------------------------------------------------
-------------------
698 | | |
701 | | postgres |
699 | | |
697 | | |
696 | | |
14572 | 00:10:31.484201 | discourse | UPDATE post_search_data
+
| | | SET private_message = X.private_message
+
| | | FROM
+
| | | (
+
| | | SELECT post_id,
+
| | | CASE WHEN t.archetype = 'private_message' THEN TRUE ELSE FALSE END pri
vate_message +
| | | FROM posts p
+
| | | JOIN post_search_data pd ON pd.post_id = p.id
+
| | | JOIN topics t ON t.id = p.topic_id
+
| | | WHERE pd.private_message IS NULL OR
+
| | | pd.private_message <> CASE WHEN t.archetype = 'private_message' THEN T
RUE ELSE FALSE END+
| | | LIMIT 3000000
+
| | | ) X
+
| | | WHERE X.post_id = post_search_data.post_id
+
| | |
14573 | 00:47:02.814489 | discourse | SELECT pg_try_advisory_lock(2859260972035668690)
(7 rows)
```
---
### Author:  [@Wingtip](https://meta.discourse.org/u/Wingtip)
#### Post date: [21 Agosto , 2020 01:02 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/2 "2020-08-21T01:02:14Z")
A atualização acabou de terminar com sucesso, justo quando meu pânico estava no auge. Ótimos momentos, ótimos momentos.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [21 Agosto , 2020 01:04 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/3 "2020-08-21T01:04:46Z")
A atualização foi bastante lenta para mim, mesmo em hardware de colocalização rápido. Não tenho certeza do motivo, mas é definitivamente algo a se ter em mente.
---
### Author:  [@Wingtip](https://meta.discourse.org/u/Wingtip)
#### Post date: [21 Agosto , 2020 01:09 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/4 "2020-08-21T01:09:32Z")
Sim, sugiro adicionar uma nota no changelog avisando as pessoas de que esta atualização provavelmente levará muito mais tempo do que a maioria, e para não encerrá-la ou tomar nenhuma medida drástica, pois isso é esperado.
---
### Author:  [@tgxworld](https://meta.discourse.org/u/tgxworld)
#### Post date: [21 Agosto , 2020 01:52 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/5 "2020-08-21T01:52:37Z")
@Wingtip Posso verificar o número de postagens que você tem no seu fórum? Infelizmente, isso será lento em sites com um grande número de postagens.
---
### Author:  [@Wingtip](https://meta.discourse.org/u/Wingtip)
#### Post date: [21 Agosto , 2020 02:08 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/6 "2020-08-21T02:08:57Z")
Sim, temos mais de 5 milhões.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [21 Agosto , 2020 02:18 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/7 "2020-08-21T02:18:13Z")
Meu site local não tinha tantos posts e ainda assim era bastante lento. Não 40 minutos de atraso, mas _notavelmente_ mais lento do que as atualizações anteriores, talvez 3 a 4 vezes mais?
---
### Author:  [@neounix](https://meta.discourse.org/u/neounix)
#### Post date: [21 Agosto , 2020 02:54 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/8 "2020-08-21T02:54:07Z")
A título de informação:
Acabei de reconstruir e agora estou executando a versão 2.6.0.beta2 ([2aa1482421](https://github.com/discourse/discourse/commits/2aa1482421920e79cab62d121f828c39d98b97a1))
O processo de build não ficou perceptivelmente mais lento no nosso servidor.
---
### Author:  [@Paracelsus](https://meta.discourse.org/u/Paracelsus)
#### Post date: [21 Agosto , 2020 06:42 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/12 "2020-08-21T06:42:14Z")
Obrigado, @Wingtip! Eu achava que isso estava acontecendo apenas conosco!
Na verdade, precisei cancelar a reconstrução e reiniciar o aplicativo porque pensei que ele tivesse travado naquela consulta que você mencionou. Temos 6 milhões de postagens e, após cerca de 45 minutos, ainda não havia concluído. Então, acho que terei que me preparar para pelo menos uma hora de reconstrução e avisar nossos usuários antes disso.
---
### Author:  [@jomaxro](https://meta.discourse.org/u/jomaxro)
#### Post date: [21 Agosto , 2020 11:16 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/13 "2020-08-21T11:16:24Z")
Uma nota sobre o tempo estendido do Docker Manager e/ou reconstrução via SSH foi adicionada às notas de lançamento.
---
### Author:  [@neounix](https://meta.discourse.org/u/neounix)
#### Post date: [21 Agosto , 2020 11:38 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/14 "2020-08-21T11:38:46Z")
Acabei de usar um cronômetro e testei uma reconstrução (site com cerca de 1 milhão de posts) da versão 2.6.0b1 para a b2; do início ao fim, levou 170 segundos.
Esta é a minha segunda reconstrução hoje, da b1 para a b2, e parece muito boa, sem diferença perceptível na velocidade de construção.
Nota: Sempre fazemos a atualização pela linha de comando e não usamos a interface gráfica.
---
### Author:  [@AntiMetaman](https://meta.discourse.org/u/AntiMetaman)
#### Post date: [21 Agosto , 2020 11:44 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/15 "2020-08-21T11:44:29Z")
Eu também não uso o gerenciador do Docker e prefiro reconstruir pela linha de comando. É melhor assim para ver o log caso algo dê errado. Também acho que é mais rápido.
---
### Author:  [@Wingtip](https://meta.discourse.org/u/Wingtip)
#### Post date: [21 Agosto , 2020 12:00 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/16 "2020-08-21T12:00:17Z")
Sim, parece que é principalmente um problema em fóruns com muitas postagens.
---
### Author:  [@Wingtip](https://meta.discourse.org/u/Wingtip)
#### Post date: [21 Agosto , 2020 13:15 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/18 "2020-08-21T13:15:29Z")
Eu (estupidamente) atualizei pelo console da web, então não tive um log atualizado o tempo todo. A última vez que cometo esse erro.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [21 Agosto , 2020 16:20 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/19 "2020-08-21T16:20:39Z")
Eu tinha um site grande que falhava repetidamente ao iniciar. É uma instalação de 2 contêineres, então o contêiner antigo continuava rodando enquanto a inicialização realizava a migração. Acabei resolvendo o problema ativando `SKIP_POST_DEPLOYMENT_MIGRATIONS=1` para a inicialização e, em seguida, executando as migrações após o novo contêiner ser iniciado. Com `SKIP_POST_DEPLOYMENT_MIGRATIONS=1` na seção ENV, a migração foi muito rápida, e o site pôde funcionar normalmente (embora talvez um pouco mais lentamente) enquanto as migrações ocorriam, o que levou, acho eu, mais de 20 minutos.
Acredito, embora ainda não tenha testado, que usar o mesmo truque funcionaria para minimizar o tempo de inatividade durante uma instalação de único contêiner. Se eu estiver certo, o que você faria seria:
- adicionar `SKIP_POST_DEPLOYMENT_MIGRATIONS=1` ao seu `app.yml`
- ./launcher rebuild app
- ./launcher enter app
- SKIP\_POST\_DEPLOYMENT\_MIGRATIONS=0 rake db:migrate
- desfazer a edição no `app.yml`, a menos que planeje lembrar de executar as migrações após cada atualização
- talvez reconstruir novamente para garantir que você não tenha nenhum problema enquanto ainda se lembra do que poderia ter quebrado seu site, pois, daqui a 4 meses, quando tentar novamente, não fará ideia e será difícil para qualquer um adivinhar qual poderia ser o problema
Se houvesse uma maneira de o `./launcher` passar `SKIP_POST_DEPLOYMENT_MIGRATIONS=1` para as coisas sem exigir uma edição no `app.yml`, tornaria as coisas menos complicadas para quem tem dificuldade com edição.
Se eu conseguir realizar o trabalho sobre isso que acredito que farei, criarei um novo tópico relatando o que descobri. Embora a fumaça me tenha confinado a um quarto onde não tenho meu monitor grande. (A pandemia não foi suficiente?! Temos que ter fumaça também? E eu nem estou especialmente perto do maldito incêndio.)
---
### Author:  [@riking](https://meta.discourse.org/u/riking)
#### Post date: [21 Agosto , 2020 23:39 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/20 "2020-08-21T23:39:03Z")
> [@pfaffman](#):
>
> Se houvesse uma maneira de o `./launcher` passar `SKIP_POST_DEPLOYMENT_MIGRATIONS=1` para os processos sem exigir uma edição no `app.yml`, isso tornaria as coisas menos complicadas para quem tem dificuldade com edição.
Boa ideia, fui lá e implementei isso:
>
>
> This will help self-hosters avoid longer downtime when a large post-deployment m…igration is pending.
>
> Usage:
>
> \`\`\`
> ./launcher rebuild app --skip-post-migrations
> ./launcher enter app
> SKIP\_POST\_DEPLOYMENT\_MIGRATIONS=0 rake db:migrate
> exit
> ./launcher restart app
> \`\`\`
>
> (Note: the 'restart' clears the temporarily-set environment variable, so future web upgrades will correctly apply post-deployment migrations.)
>
> https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/19?u=riking
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [21 Agosto , 2020 23:42 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/21 "2020-08-21T23:42:57Z")
Isso é uma notícia fantástica! (Outros dois projetos atrapalharam hoje e, de alguma forma, minha instância multisite parou de funcionar e de se dar bem com o S3. 😿) Muito obrigado.
---
### Author:  [@Wingtip](https://meta.discourse.org/u/Wingtip)
#### Post date: [22 Agosto , 2020 04:35 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/22 "2020-08-22T04:35:37Z")
Existe algum motivo técnico para que as alterações no banco de dados após a atualização sejam bloqueantes por padrão? Há alguma maneira de alterar esse comportamento para que as futuras atualizações restaurem o site rapidamente e, em seguida, executem as tarefas pós-atualização em segundo plano?
Na minha opinião, qualquer coisa essencial para o funcionamento da aplicação atualizada, como DDL, deveria fazer parte da própria atualização, e não de scripts pós-atualização.
---
### Author:  [@Paracelsus](https://meta.discourse.org/u/Paracelsus)
#### Post date: [22 Agosto , 2020 06:47 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/23 "2020-08-22T06:47:30Z")
Começamos nossa reconstrução pela linha de comando há sete horas! E ainda está em andamento… Ainda está aqui:
Alguma ideia?
Edição: enquanto isso, matei o processo para colocar o site no ar novamente para nossos usuários. Mas tem que haver uma maneira melhor de fazer essa atualização.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [22 Agosto , 2020 09:04 UTC](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604/24 "2020-08-22T09:04:26Z")
Você tem um banco de dados grande?
[Próxima página](https://meta.discourse.org/t/2-6-0b2-upgrade-very-slow/161604.md?page=2)