Ah, entendi, isso terá dificuldade com essa consulta. Após atualizar para a versão mais recente, você poderia extrair a consulta do mini_profiler, executar um explain analyze nela e compartilhar conosco?
No Meta (RDS db.r6g.large 30GB), parece assim:
Vou tentar executar o explain analyze novamente, mas não conseguimos fazer com que essa consulta seja concluída com sucesso.
Atualização: este commit não alterou nada. O banco de dados continua operando acima de 95% constantemente após a atualização, matando todas as consultas antigas em execução. Na versão beta4, ele operava com uma cadência estável de 20-30% para este fórum. Já executamos um auto-vacuum e reindexação do esquema também.
Como desabilitamos esse recurso? Não parece correto precisar de uma instância de banco de dados maior para resolver isso; parece haver algo errado na forma como essa consulta é computada, dado que funcionava perfeitamente antes desta atualização.
A consulta conseguiu terminar após ~21 minutos
Vale ressaltar também que estamos no PG 10.17, já que parece que nossos resultados diferem bastante.
Monkey-patchamos o problema reencaminhando temporariamente todas as rotas */private-messages-all/* apenas para */private-messages/*. O resultado é que “todas as caixas de entrada” têm o mesmo conteúdo que “Pessoal”, mas pelo menos não precisamos mais lidar com uso de 100% da CPU constantemente dessa forma.
Código do monkeypatch:
# name: discourse-private-messages-perf-hotfix
# version: 0.0.1
# authors:
# Prepend to override existing routes
Discourse::Application.routes.prepend do
scope path: nil, constraints: { format: /(json|html|\*\/\*)/ } do
scope "/topics", username: RouteFormat.username do
# Reroute all */private-messages-all/* routes to go to */private-messages/* instead (personal messages)
# Former is expensive, latter is cheap, potentially saves significant database CPU usage
get "private-messages-all/:username" => "list#private_messages", as: "topics_private_messages_override", defaults: { format: :json }
get "private-messages-all-sent/:username" => "list#private_messages_sent", as: "topics_private_messages_sent_override", defaults: { format: :json }
get "private-messages-all-new/:username" => "list#private_messages_new", as: "topics_private_messages_new_override", defaults: { format: :json }
get "private-messages-all-unread/:username" => "list#private_messages_unread", as: "topics_private_messages_unread_override", defaults: { format: :json }
get "private-messages-all-archive/:username" => "list#private_messages_archive", as: "topics_private_messages_archive_override", defaults: { format: :json }
end
end
end
Uso de CPU do banco de dados do nosso fórum após implantar o monkeypatch acima:
@tgxworld Você precisará dar outra olhada no que as rotas */private-messages-all/* estão fazendo. Claramente, há algo errado na forma como foram implementadas; não são eficientes o suficiente para bancos de dados de fóruns grandes. Ou a implementação não está usando o índice de banco de dados correto, ou a geração de consultas está resultando em consultas extremamente custosas (especialmente no PSQL 10, não tenho certeza sobre as versões 12/13).
A implementação atual basicamente deixou nosso fórum inutilizável, aumentando o uso de CPU de ~15% para 100% constante e causando lentidão em todos os outros recursos do fórum. Não vejo nenhuma razão para que as consultas da caixa de entrada Pessoal/grupo levem menos de 50 ms, enquanto as de “todas as caixas de entrada” levem mais de 20 minutos para serem concluídas.
Você pode usar o dump de análise que @forkythetoy postou logo acima para ver a execução de mais de 20 minutos que ocorria antes.
@Falco Acabei de notar que você fundiu nosso tópico aqui, mas isso parece ser sobre um endpoint diferente. Este relatório de bug é sobre o endpoint private-message-topic-tracking-state, mas estamos falando de */private-messages-all/*. Isso pode estar causando parte da confusão aqui, peço desculpas por isso. (Inicialmente, vinculei a este, o que pode ter iniciado a confusão)
O private-message-topic-tracking-state é rápido em nosso fórum, então esse não é o problema para nós.
Para nós, essa consulta leva cerca de 200 a 300 ms de tempo de banco de dados. Um pouco mais do que se esperaria, mas ainda dentro dos limites normais, sim.
No entanto, estamos usando Postgres 13.
@Hooksmith tenho uma correção em andamento
@Hooksmith @forkythetoy Vocês conseguirão atualizar para o PG 13? Essa é a versão mínima exigida pelo Discourse no momento. Além disso, fica mais difícil para mim comparar os planos de consulta quando as consultas não são executadas na mesma versão do PG.
Fui obrigado a reverter isso porque o desempenho da nova consulta difere muito entre os usuários.
@blattersturm Você ainda está vendo que o desempenho do rastreamento de estado de tópicos está lento?
Incerto, não fiz nenhuma atualização há alguns dias. Há algum commit para verificar se algo melhorou?
Não, nada mudou, mas se você puder me fornecer um EXPLAIN ANALYZE da consulta, isso será útil.
Observe que reverteremos as caixas de entrada “todas” por enquanto devido a preocupações com o desempenho.
Este tópico foi automaticamente fechado após 14 dias. Novas respostas não são mais permitidas.
