Solução de problemas de um site lento que era bastante rápido até esta manhã

[omarfilip]

Como posso solucionar um site que ficou lento (sem motivo aparente) hoje?

O uso de recursos está muito baixo:

Este é um droplet de 16 GB de Memória / 4 vCPUs AMD / 200 GB de Disco / SFO3 - Ubuntu 24.04 (LTS) x64 com 30% de disco utilizado.

O Status do serviço da DigitalOcean esteve normal o dia todo.

A lentidão do site foi relatada em vários locais por usuários.

yaml:
UNICORN_WORKERS: 8
db_shared_buffers: "1024MB"
db_work_mem: "40MB"

Reconstruí para a versão mais recente e dei mais memória ao Sidekiq UNICORN_SIDEKIQ_MAX_RSS: 1000

Alguns erros 429 no console:

O log de erros dos últimos 3 dias:

[Lilly (Lillian Louis)]

o que acontece no modo de segurança?

[omarfilip]

Não recebo erros no console em modo de segurança, mas é muito mais lento. Leva cerca de 10-15 segundos para carregar qualquer coisa e as imagens estão travando como se estivessem vindo de um modem de 14,4 Kbps.

Levou cerca de 20 segundos para carregar /logs. Voltar para /admin levou cerca de um minuto.

Uma “enquete” parece demorar muito:

A propósito, estes são os plugins em execução:

• git clone GitHub - discourse/docker_manager: Plugin for use with discourse docker image
• git clone GitHub - discourse/discourse-data-explorer: SQL Queries for admins in Discourse
• git clone GitHub - merefield/discourse-locations: Tools for handling locations in Discourse
• git clone GitHub - discourse/discourse-affiliate
• git clone GitHub - discourse/discourse-yearly-review: Publishes an automated Year in Review topic
• git clone GitHub - discourse/discourse-docs
• git clone GitHub - discourse/discourse-subscriptions: A Discourse plugin that allows payments and subscription management via Stripe.
• git clone GitHub - paviliondev/discourse-category-lockdown: Set all topics in a category to redirect, unless a member of specified groups
• git clone GitHub - discourse/discourse-reactions: Moved to https://github.com/discourse/discourse/tree/main/plugins/discourse-reactions

[omarfilip]

Aqui estão mais alguns pontos de dados desta manhã. O Sidekiq parece tranquilo:

Gráfico de memória interessante - após as reconstruções do aplicativo, fica em cerca de 20-30%, depois salta para 46% durante um backup e permanece lá:

[Falco]

Você tem o infame componente de tema “badges in posts” instalado?

[omarfilip]

Este aqui?

[Falco]

Topic history not loading correctly after migration

It’s so much easier with the URL! Your problem is that you are using the theme-component Post Badges. It’s awful for performance, so please remove it ASAP. Don’t forget to re-enable all you disabled during this journey and thanks for persisting.

[omarfilip]

Uau! Noite e dia depois de remover o componente Post Badges. Desabilitá-lo não fez diferença, mas excluí-lo fez. Sem mais erros no console também.

Obrigado @Falco!

[omarfilip]

Bem, receio que não foi isso, ou pelo menos não tudo.

Agora estou vendo imagens quebradas e isto no console:

Ainda carregando lentamente ou não carregando nada com o spinner girando…

[omarfilip]

Será que isso tem algo a ver com o problema:

@david

Portanto, se você restaurar um backup e não reassarar, verá imagens quebradas em seu site. O reassaramento é necessário para regenerar essas imagens otimizadas. O Discourse cuidará disso automaticamente quando você restaurar um backup.

Restaurei o Discourse de um backup há cerca de 4 semanas, quando o movi de um antigo droplet Ubuntu 16.4 LTS para um novo rodando Ubuntu 24.04. Não fiz um reassaramento manual.

[omarfilip]

Fica cada vez mais estranho. Isso acontece ao ir de /logs para /admin clicando no link “Voltar ao site”.

[Moin]

Houve outro tópico recente com o erro “no route named admin”.
Site Glitch Content Not Showing Up - #18 by Suresh_Suthar

Talvez isso também esteja relacionado ao Cloudflare
Resolving "SyntaxError: Unexpected identifier #..." caused by Cloudflare Auto Minify

[omarfilip]

Hmm. O meu não está usando Cloudflare, mas eu vi um cabeçalho duplicado no Chrome, como na primeira postagem lá.

Acabei de reconstruir sem plugins além do docker_manager, então relatarei como ele se comporta.

Outra coisa a notar é que quando ele trava no Chrome, tive que fechar essa aba e abrir em uma nova. Recarregar à força não fez nada.

[omarfilip]

Agora o backup noturno para o S3 está falhando sem nenhuma alteração na configuração:

[2024-10-10 15:03:04] Uploading archive...
[2024-10-10 15:14:33] EXCEPTION: multipart upload failed: Net::WriteTimeout with #<TCPSocket:(closed)>

EDIT: Dois backups acionados manualmente falharam com o mesmo erro acima, mas depois dois backups manuais foram bem-sucedidos. Tudo sem alterações na configuração.

[omarfilip]

Não estou vendo erros no console, apenas tempos de carregamento muito lentos intermitentemente:

O Discourse Doctor parece estar bem em uma execução, então em uma segunda execução relata que a porta 587 provavelmente está bloqueada, o que é estranho porque entregou o e-mail de teste na primeira execução e novamente com sucesso na terceira execução:

Falha na conexão com a porta 587.
====================================== SOLUÇÃO =======================================
O problema mais provável é que seu servidor esteja bloqueando o tráfego SMTP de saída.
Se você estiver usando um serviço como Mailgun ou Sendgrid, tente usar a porta 2525.

Estou certo em pensar que há algo estranho com esta droplet do DigitalOcean?

[omarfilip]

Parece que este droplet tem alguns problemas de rede - o download está bem lento, mas observe a velocidade de upload :

speedtest-cli
Retrieving speedtest.net configuration...
Testing from Digital Ocean (24.199.xxx.xxx)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Next Level Infrastructure (Santa Clara, CA) [4.38 km]: 2.242 ms
Testing download speed................................................................................
Download: 839.25 Mbit/s
Testing upload speed......................................................................................................
Upload: 1.27 Mbit/s

[omarfilip]

Aqui está a feliz conclusão desta saga…

Após executar os testes de taxa de transferência de rede speedtest-cli e iperf3, que mostraram velocidades abismalmente lentas entre o droplet e o mundo exterior, pedi à DigitalOcean para investigar e eles concluíram após fazerem seus próprios testes:

Descobrimos alguns problemas com o hypervisor onde seu Droplet está localizado. Estamos trabalhando com nossa equipe de backend para migrar seu Droplet para outro hypervisor.

Tudo está bem novamente.