Olá a todos,
Upgradeamos nosso servidor CentOS 7 da versão 2.2.2 para a 2.7.0.beta4 e, desde então, temos enfrentado latência no carregamento das páginas. Isso é especialmente perceptível em páginas que envolvem banco de dados ou conteúdo de imagens, a ponto de o sistema se tornar inutilizável.
Qualquer orientação sobre esse assunto seria muito apreciada.
Várias coisas aconteceram nos últimos anos. Houve uma mudança de bug que exige o processamento de todas as imagens. Suspeito que seu servidor esteja sobrecarregado com esse trabalho. Você pode verificar /sidekiq para ver a fila.
Qual o tamanho do seu banco de dados? Quantas imagens? O que o Sidekiq mostra? Você está usando SSD, certo?
É um servidor baseado em VM, então não tenho certeza se é SSD ou não.
Não consigo acessar o Sidekiq, já que essa implantação não foi feita por mim, então não sei como acessá-lo.
Você sabe como foi instalado? Parece que não é uma instalação padrão (caso contrário, /sidekiq estaria disponível para você se você fosse um administrador).
O melhor caminho a seguir é investigar por que o desempenho caiu. Há muitos jobs em segundo plano adicionados ao longo dos anos (otimização de imagens, rebaking, etc.) que provavelmente estão sendo executados agora e consumindo os recursos do seu servidor. Assim que esses jobs forem concluídos, o desempenho deve melhorar.
Acessar /sidekiq (usando uma conta de administrador!) para descobrir quais jobs estão em execução é um ótimo primeiro passo.
O comportamento que observo no servidor é que ele continua exibindo essa fila vazia, mesmo quando tento abrir uma postagem para vê-la listada. Além disso, o portal Sidekiq também trava ao carregar a postagem e só atualiza quando a postagem estiver totalmente carregada.
Além disso, assim que é carregada, ela mostra uma fila vazia. Qualquer ajuda ou sugestão será muito apreciada.
Se a fila estiver vazia, então você não tem o problema de muitas tarefas em segundo plano sendo executadas. Portanto, é algo diferente.
Você tem algum plugin? Você tem componentes de tema que estão fazendo muitas chamadas de API?
Fiz algumas outras perguntas acima.
Qual o tamanho do seu banco de dados?
Quantas imagens?
Você tem componentes de tema que estão fazendo muitas chamadas de API?
Você pode me dizer como posso obter essas informações a partir de uma configuração baseada em Docker? Sei que o último backup tem 135 MB.
Quanto aos plugins, sim, temos os seguintes plugins listados:
- git clone https://github.com/discourse/docker_manager.git
- git clone https://github.com/jonmbake/discourse-ldap-auth.git
- git clone https://github.com/discourse/discourse-math
- git clone https://github.com/discourse/discourse-chat-integration.git
- git clone https://github.com/discourse/discourse-voting.git
- git clone https://github.com/unfoldingWord-dev/discourse-mermaid.git
- git clone https://github.com/discourse/discourse-solved.git
- git clone https://github.com/discourse/discourse-assign.git
- git clone https://github.com/discourse/discourse-knowledge-explorer.git
- git clone https://github.com/discourse/discourse-cakeday.git
Recomendo remover o plugin Mermaid.
Quantas publicações e usuários você tem? E o tráfego?
Quanta memória RAM você tem?
Parece que você ficaria bem com um droplet DigitalOcean de 2 GB; talvez você possa criar um e ver como funciona.
Talvez haja algum outro problema no seu servidor? Ele está atualizado? Foi reiniciado recentemente?
Ok, vou remover isso.
Temos aproximadamente 4 mil postagens e cerca de 350 usuários.
A média de usuários conectados simultaneamente não é muito alta, talvez no máximo 5 a 10 em média.
Este servidor foi criado recentemente e compartilha 8 GB de RAM com 10 GB de espaço de swap. Até o momento, está em execução há apenas 13 dias. No entanto, os problemas de desempenho ocorrem independentemente de reinicializações ou tempo de atividade.
Definitivamente, há algo errado com sua instalação; você deveria obter um desempenho muito melhor com esse hardware.
Tente executar um VACUUM explícito no PostgreSQL. Se você estiver usando a instalação do contêiner tudo-em-um:
# docker exec -it -u postgres app psql discourse
psql (13.1 (Debian 13.1-1.pgdg100+1))
Digite "help" para obter ajuda.
discourse=# VACUUM ANALYZE;
VACUUM
Quantos workers do Unicorn você configurou no seu app.yml?
Você pode pedir ao Discourse para incluir cabeçalhos de desempenho adicionais nas respostas adicionando o seguinte à sua seção env:
DISCOURSE_ENABLE_PERFORMANCE_HTTP_HEADERS: true
Enquanto está nisso, você pode ativar o miniprofiler seguindo esta postagem.
Isso deve ser bastante suficiente.
Não me lembro se foi sugerido que você executasse discourse-setup novamente para ajustar o uso de memória do Discourse, ou se essas configurações padrão são razoáveis, considerando o que mais está usando o servidor.
Se você não reindexou o banco de dados após a atualização para o PG13, talvez valha a pena dar uma olhada em Atualização do PostgreSQL 13 para obter mais informações sobre isso.
Ah, sim, a falta de estatísticas de tabela (VACUUM ANALYZE) é o culpado mais provável aqui.
VACUUM FULL VERBOSE;
REINDEX DATABASE discourse;
VACUUM VERBOSE ANALYZE;
Então, executei esses comandos e configurei o cabeçalho no ambiente também, mas não observei muita diferença no tempo de carregamento da página.
Estou rodando 8 unicorns.
Você executou esses comandos no PostgreSQL, certo?
Sim, executei docker exec -it -u postgres app psql discourse antes de rodar os comandos acima.
Bem, isso é tudo muito estranho. Ninguém mais teve problemas assim. Você parece ter hardware suficiente. Minha única suposição é algum problema com um proxy reverso (acho que você tem outras coisas na máquina?).
Sim, outro serviço baseado em Docker.
Mas nada realmente intensivo em termos de desempenho, já que isso se refletiria nas métricas de desempenho da máquina.
