Estou principalmente perplexo quanto a como o desempenho pode oscilar entre concluir ~11 milhões e ~300 mil jobs em um dia, dentro de ~1 semana, com a mesma configuração. Uma diferença de velocidade de ~35x em termos de jobs por segundo.
Quanto ao uso da CPU, ele voltou a ~15-20%, que é o habitual. Processando jobs na mesma velocidade (lenta).
Apenas para esclarecer/confirmar, eu quis dizer atribuir (não adicionar) alguns sidekiqs exclusivamente para processar a fila de baixa prioridade, já que parecia que as tarefas de baixa prioridade podiam ser processadas a uma taxa muito mais rápida e possivelmente não sofrem os mesmos gargalos. Eu especulava que isso poderia explicar como os jobs por segundo podem variar tão drasticamente (ou seja, tarefas ‘fáceis’ de baixa prioridade presas atrás do backlog da fila padrão).
Para esclarecer: você acha que o desempenho do PostgreSQL está causando a conclusão lenta dos jobs ou apenas o evento de alto uso de CPU que notei ontem (que agora voltou ao normal)?
Atualização: Tentei excluir a fila de baixa prioridade e a fila padrão algumas vezes, sem impacto na velocidade, pois a fila padrão volta a crescer imediatamente. Em seguida, tentei excluir a fila padrão e ativar o modo somente leitura. Isso fez com que o número de tarefas por segundo disparasse dramaticamente, esvaziando a fila de baixa prioridade a uma velocidade cerca de 100 vezes maior.
Edição: Parece que, mesmo com apenas uma fila de baixa prioridade grande, a velocidade de processamento ainda é lenta. Se eu definir o Discourse como somente leitura e depois esvaziar tanto a fila de baixa prioridade quanto a fila padrão, o processamento subsequente de tarefas parece permanecer super rápido, esvaziando as tarefas agendadas e as filas até que eu desative o modo somente leitura.
Meu próximo passo seria descobrir exatamente qual processo está causando o problema, acessando o aplicativo Discourse e executando o htop ou top para verificar os maiores usos de CPU.
Parece que o PostgreSQL é o gargalo. Você pode configurar o Prometheus para monitorar seu desempenho e verificar se ele tem acesso suficiente à memória RAM.
Obrigado pela sua contribuição, @pfaffman Acredito que db_shared_buffers e db_work_mem no app.yml sejam os únicos controles para o acesso à RAM do PostgreSQL, certo?
Fiz alguns ajustes, tanto para cima quanto para baixo. As configurações atuais no app.yml são:
db_shared_buffers: “32768MB”
db_work_mem: “128MB”
Com uma memória RAM total do sistema de 128 GB.
Também tentei alterar max_connections em /var/discourse/shared/standalone/postgres_data/postgresql.conf e depois reconstruir o Discourse. Testei valores acima do padrão (100), de 200 a 500. Atualmente está configurado para 300. Não tenho certeza se modificá-lo ali realmente altera o valor máximo de conexões.
Vejo estas configurações em /var/discourse/templates/postgres.template.yml:
Obrigado @bartv, seguindo sua sugestão, tenho monitorado de dentro do aplicativo Discourse via top. Estou vendo muitos processos postmaster executados pelo usuário postgres — a quantidade de uso de CPU varia. As capturas de tela representam períodos prolongados com estatísticas de uso semelhantes.
Você deve se informar sobre o ajuste do PostgreSQL. Esse nível de desempenho está um pouco além do auto-hospedagem típica vista aqui.
Eu tentaria reservar cerca de 3/4 da RAM para o PostgreSQL. Com certeza eu separaria em containers de dados e web distintos. Mas você pode precisar de uma configuração mais complexa do PostgreSQL para obter o desempenho necessário.
EDIT: Mas eu não tenho experiência com bancos de dados muito maiores, então veja abaixo!
Tentei executar consultas, mas recebi o seguinte erro:
ERROR: pg_stat_statements deve ser carregado via shared_preload_libraries
Minha suposição é que minhas edições no arquivo postgresql.conf (/var/discourse/shared/standalone/postgres_data/postgresql.conf) não estão funcionando (recompilei o Discourse após editar). É possível fazer essas edições através do arquivo app.yml? Ou você vê algo que eu tenha feito de errado?
Reconstruir o Discourse apagará essas alterações. Reiniciar o container provavelmente resolverá o problema. (algo como sv restart postgres dentro do container também pode funcionar).
Obrigado, isso ajudou muito, no início. . O problema parecia resolvido e a fila de jobs estava rodando muito rápido apenas aumentando as conexões máximas no postgresql.conf. Infelizmente, desacelerou novamente após cerca de um dia.
Abaixo estão os passos, caso sejam úteis para outras pessoas que queiram aumentar o max_connections do PostgreSQL.
docker ps
Obtenha o ID do contêiner, por exemplo, aaabbbccc123, e substitua nos comandos abaixo:
Copie o arquivo postgresql.conf de dentro do contêiner Docker para o sistema de arquivos local:
I can’t really read the result though, I think I’ve done something wrong.
total | avg | query
1671.1110420745 | 374.736186677194 | SELECT COUNT(*) FROM ( +
| | SELECT $1 FROM +
| | notifications n +
| | LEFT JOIN topics t ON t.id = n.topic_id +
| | WHERE t.deleted_at IS NULL AND +
| | n.notification_type <> $2 AND +
| | n.user_id = $3 AND +
| | n.id > $4 AND
Agora que você sabe o que deseja fazer, pode aplicar essas alterações usando um bloco replace no seu app.yml.
Além disso, você pode simplesmente executar ./launcher enter app e editar os arquivos diretamente. Observe, no entanto, que ao reconstruir, essas alterações não estarão presentes no novo contêiner.
Acredito que 
. O problema parecia resolvido e a fila de jobs estava rodando muito rápido apenas aumentando as conexões máximas no postgresql.conf. Infelizmente, desacelerou novamente após cerca de um dia.