- Às vezes, o banco de dados é desativado devido a algumas consultas, e nos foi dito que precisamos otimizar o PostgreSQL, alguma ideia de como conseguir isso?
Na tela abaixo estão os recursos do nosso banco de dados
- CPU: 4 vcpu
- Memória: 22 GB
1 curtida
Olá a todos, estou trabalhando nisso com o @Abdelrahman_MoHamed. Recentemente, migramos um site com aproximadamente 500 mil tópicos e 3,5 milhões de usuários para o Discourse. Estamos auto-hospedados no GCP. Durante este processo, nosso parceiro que auxiliou na migração mencionou que poderia fazer sentido otimizar o Postgres para obter o desempenho adequado do banco de dados. Nossa suposição era que o banco de dados viria otimizado para o Discourse pronto para uso (talvez venha?). No entanto, dada a sugestão deles (do parceiro), queríamos acompanhar aqui.
Resumindo, estas são algumas maneiras comuns de otimizar o Postgres para um banco de dados com os números postados aqui?
Agradeço antecipadamente pela ajuda!
1 curtida
Você tem evidências mais detalhadas de que o DB é o fator limitante, ou a causa dessas cargas de CPU? Saída de ps ou top, por exemplo.
Se for o DB, imagino que haja alguma maneira de perguntar a ele em quais consultas ele está trabalhando.
Tais detalhes podem ser úteis.
1 curtida
Obrigado @Ed_S, adicionaremos mais dados aqui em breve. Por enquanto, estamos apenas monitorando as coisas. Agradeço a resposta.
1 curtida
isso realmente parece uma combinação estranha… 22 GB de memória, mas apenas 4 vCPUs? Exagero na memória, mas potencialmente poucas cores.
Normalmente, você teria um servidor com muito mais vCPU por GB.
Isso ocorre porque o serviço web é muito paralelo e para cada unicórnio você precisa de apenas cerca de 1 GB.
Cada unicórnio pode rodar em um núcleo diferente, acredito.
Este pode ser o motivo pelo qual você está atingindo 100% de utilização da CPU tão facilmente.
Eu recomendo que você considere mudar para uma configuração 16/16 ou até mesmo 8/8 e veja se as coisas melhoram.
Um pequeno desvio é permitido? Unicórnios são algo semelhante aos workers do PHP? Algum documento tentou explicar que unicórnios são, na verdade, servidores HTTP com seus próprios workers entregando requisições para Ruby, e é por isso que é totalmente diferente. Mas ambos lidam com requisições HTTP, permitindo mais requisições concorrentes e, portanto, mais workers PHP e mais unicórnios precisam de mais RAM — e para mim, esses dois são praticamente a mesma coisa.
Certo ou terrivelmente errado? Eu gostaria de entender o princípio agora, porque eu sei por que, quando e como ajustar os workers PHP, mas unicórnios são apenas criaturas místicas e mágicas para mim.
sim, acho que é uma comparação justa
1 curtida
Relacionado: Como um administrador pode descobrir se tem poucos ou muitos unicórnios para o tráfego da web?
Relacionado: Como um administrador pode descobrir se tem muito mais RAM do que precisa?
Meu entendimento é que o número de unicórnios é geralmente dimensionado de acordo com o número de CPUs, mas não precisa ser assim - se, por exemplo, a configuração do host mudou desde a configuração.
A quantidade de RAM deve ser dimensionada de acordo com o quanto é necessário. Não sei se uma importação enorme de muitos posts e usuários necessariamente significa que mais RAM é necessária - a questão seria, quanta parte do banco de dados é acessada para atender a cada solicitação da web ou a cada tarefa regular?
Para mim, um surto de 10 minutos de uso máximo de CPU, em um contexto de uso muito baixo, não indicaria um problema. (Seria um problema se significasse que um fórum muito movimentado e com tempo crítico, como um fórum de esportes/apostas, tivesse algum atraso no atendimento de páginas em momentos de pico de interesse. Mas meu fórum não é crítico em tempo ou desempenho.)
Não sei como se poderia tabular a faixa de tempos de resposta recentes, mas isso pode ser um bom dado a ser observado. Seja do lado do servidor web ou do lado do banco de dados.
1 curtida