Restauramos todos os valores ajustados para os padrões e atualizamos para a versão 2.6.0 beta4. Jogos estão agendados para quinta e sexta-feira, então teremos uma boa cobertura de testes no final desta semana.
Infelizmente, a correção não resolveu o problema. Tivemos um jogo moderadamente ativo com 600 mensagens. Vários travamentos foram observados em meus próprios testes, assim como por nossos membros. Eles correlacionam-se com eventos do jogo, ou seja, picos de atividade.
- O uso da CPU estava bem dentro dos limites, atingindo cerca de 60% no pico e uma carga média de 30%.
- Definitivamente um problema no lado do cliente. Quando o tópico do chat trava, se você for para a página inicial verá a contagem de mensagens não lidas. Clique de volta no tópico e as mensagens ficarão visíveis.
O que ainda me deixa perplexo e não é abordado neste tópico é: o que mudou desde a versão 2.3, que não apresentava esse problema?
As principais atualizações 2.4 e 2.5 ocorreram durante nossa temporada morta (estendida pela COVID), então ninguém notou nada, mas o travamento ficou evidente imediatamente no primeiro jogo de exibição da pré-temporada.
Há alguma manipulação de parâmetros que possamos tentar para amanhã? Será um clássico intenso e um jogo fora de casa, então a comunidade estará em ebulição.
No nosso caso, desativar o plugin Who’s Online e desativar o arquivo de limitação de taxa (e li que houve algumas melhorias na versão beta mais recente) parece ter resolvido o problema para nós.
Temos também jogos de futebol de vez em quando, com 300 usuários ou um pouco mais clicando e escrevendo todos no mesmo tópico ao mesmo tempo, e parece que o desempenho foi muito melhor durante o último jogo.
Você está na versão mais recente, com a correção recente?
Por favor, atualizem para “testes aprovados”. Refinei bastante as coisas desde a beta.
Sim, a versão beta mais recente (ou seja, até as últimas 48 horas).
Atualizado. O relatório seguirá.
Infelizmente, ainda não é possível. Claro, o jogo foi intenso com 950 mensagens. Fiquei de olho no GAnalytics e, por volta de 250 pessoas estavam assistindo, 119 postaram. Vários congelamentos foram observados, como antes. O message-bus retornou alguns erros 429, com mensagens “Você executou esta ação muitas vezes, por favor aguarde X minutos”.
A carga da CPU atingiu o pico de ~70% e não houve praticamente nenhuma espera (wa). Portanto, embora a atividade tenha sido alta, ainda não conseguimos entregar o que o hardware seria capaz de fazer.
Você poderia responder a uma pergunta que me deixou confuso: o que foi implementado após a versão 2.3 que está causando isso? O que se supõe que isso traga de novo?
A implementação é basicamente a mesma de sempre, exceto pelo fato de que temos limites de taxa globais para o aplicativo, que são configuráveis. Você pode aumentá-los se quiser, mas isso poderia causar um colapso total; não sei.
Não entendi o que você quer dizer com travamentos. Se o sistema ficar muito sobrecarregado agora, ele parará de atualizar, mas a diferença é que você não precisa recarregar o navegador para corrigir a página; ela se recuperará assim que o servidor tiver capacidade.
Um pouco confuso aqui: seus usuários estão observando nenhuma melhoria após minhas alterações?
Seu servidor tem muita memória RAM livre? Se sim, adicione workers do Unicorn.
O que você tem no parâmetro db_shared_buffers? Tivemos muito comportamento “instável” no início (alguns tópicos “consomendo” muito, especialmente quando muito participativos) com apenas os 25% recomendados da RAM total. Quando aumentamos para 16 GB (de um total de 32 GB), toda essa instabilidade desapareceu… e mais recentemente, com as últimas mudanças, ficou ainda melhor.
Certo, então esse fenômeno é difícil de monitorar em um ambiente de produção (chats de jogos), já que cada jogo é diferente — quantidade diferente de eventos críticos, oponente diferente, carga emocional diferente e assim por diante.
O problema, do nosso ponto de vista, é que nossa capacidade máxima de atendimento diminuiu desde a versão 2.3. Esse é o ponto chave. Todo servidor tem seus limites, mas agora estamos obtendo menos desempenho do que obtivemos em março, quando rodávamos a versão 2.3. Com base em uma monitorização aproximada do back-end, o servidor não consegue atingir 100% de carga ou capacidade.
O que o usuário final vê é que o fluxo do chat simplesmente para, sem nenhuma indicação na interface do usuário sobre o que está acontecendo. Isso causa confusão.
Tenho bastante certeza de que as alterações nos testes aprovados melhoraram a situação, mas o desempenho ou a saída máxima ainda é significativamente menor do que com a versão 2.3.
Temos um VPS com 6 núcleos rápidos e 16 GB de RAM. Os processos Unicorn estão configurados para 12, e as configurações relacionadas ao buffer de RAM estão nos padrões.
Acho que o próximo melhor passo aqui é configurar o monitoramento histórico do seu sistema para que possamos identificar onde está o gargalo, pois já estabelecemos que não é o tempo de CPU. É sempre possível que você esteja saturando sua conexão de rede!
mais métricas de servidor mais tradicionais, como o node-exporter.
Se for esse o caso e você quiser forçá-lo mais.
-
Você pode reduzir os limites de taxa, o que permitirá que os usuários interajam de forma mais agressiva com o Discourse. Especificamente, você poderia dobrar
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTEeDISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS. -
Você pode tentar adicionar mais workers do unicorn.
Isso é esperado temporariamente enquanto você estiver sobrecarregado, mas as coisas devem se recuperar automaticamente assim que a carga diminuir.
Minha suposição aqui é que tudo isso está relacionado apenas aos limites de taxa; os limites de taxa são novos e existem para proteger o servidor. Parece que seu servidor está sendo protegido por design.
Tentamos um jogo com…
DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS: 0.3
DISCOURSE_MAX_REQS_PER_IP_MODE: none…e, quando as emoções começaram a aquecer no terceiro período, as coisas pioraram. Alcançamos os limites dos nossos servidores, os usuários eram constantemente desconectados para o modo deslogado e o chat do jogo também travava.
Foi uma grande história de sucesso por 4 anos, mas agora estamos em uma situação muito delicada. Saltar para o próximo nível de capacidade de VPS nos levaria à faixa de preço de ~160€/mês, o que é um desafio para um site de hobby. Não estamos falando de volumes enormes de usuários: 116 pessoas publicaram mais de 800 mensagens durante o jogo.
A ideologia de “não fazer chats” também não é adequada. Se não tivéssemos esses chats, as postagens de reações emocionais se espalhariam por todos os tópicos mais “sérios”. Eles são uma ferramenta importante para canalizar a carga emocional da situação ao vivo para um único tópico, mantendo os tópicos mais analíticos limpos.
O meu é um fórum de futebol e já enfrentei desafios semelhantes.
Basicamente, o que percebi é que se trata de um problema de escalabilidade.
Os problemas começaram a surgir em diferentes níveis.
Digital Ocean
1 CPU e 1 GB = 30 a 40 usuários em situação de chat
2 CPUs e 2 GB = 70 a 80 usuários em situação de chat
4 CPUs e 8 GB = adequado para 120 usuários e 1.000 posts em 2 horas. Não atingi o limite.
Estou testando níveis de upgrade diferentes com a Hetzner (site espelho), por ser mais barata, mas as coisas não correram tão bem quanto esperado.
Minha experiência até agora é:
3 CPUs (chip AMD CPX 21) e 4 GB = com dificuldades com 20 usuários
2 CPUs (Intel) e 8 GB = sem problemas com 20 usuários.
Estou prestes a testar com 80 a 100 usuários simultâneos sob condições de partida.
Quando analisei o uso de CPU na Digital Ocean, mesmo sob estresse, o uso da CPU parecia bastante baixo, sempre abaixo de 50% em todos os níveis.
Quando analisei a CPU da Hetzner para o chip AMD, observei um uso mediano de CPU de cerca de 60%, mas a cada minuto ou mais ocorria um pico curto de até 300% de uso de CPU. Isso não pareceu ocorrer com o chip Intel.
O que isso significa, não sei. Suspeito que o monitoramento de CPU seja melhor na Hetzner (capturando picos curtos). Mas, no geral, o uso de CPU parece bem equilibrado. A Digital Ocean, à primeira vista, parece lidar melhor com picos, mas terei mais informações sobre a Hetzner após este fim de semana.
Também devo acrescentar que, no teste com a Hetzner, o plugin ‘whose online’ não fez nenhuma diferença.
No entanto, o plugin de mensagens rápidas do Discourse pareceu ser prejudicial.
O próximo jogo está previsto para amanhã. Removemos nossas próprias modificações e estamos testando com essas.
Além disso, como uma tentativa totalmente improvável, aumentei o db_shared_buffers de 4 GB (25%) para 6 GB (37,5%). Também descomentei a linha db_work_mem 40MB do app.yml (por sinal, essa é uma opção muito vagamente documentada, embora ainda seja apresentada ao administrador como uma espécie de oportunidade de melhoria).
Não espero mais encontrar uma solução definitiva para o problema, mas apenas um controle de danos mais eficaz — um conjunto de parâmetros que cause o menor impacto negativo na experiência do usuário final. Enquanto isso, terei que avaliar as possibilidades de aumentar ainda mais nossos recursos de hospedagem.
Pergunta para @sam e outros desenvolvedores.
Como o crescimento contínuo do tamanho do banco de dados impacta esse caso de uso, onde os usuários pressionam um único tópico por algumas horas?
Analisei a atividade histórica de chats de jogos e notei que tínhamos jogos com estatísticas enormes em 2017, quando nosso servidor tinha uma fração dos recursos que temos hoje. Tivemos jogos onde a contagem de mensagens atingiu 1600 mensagens por 165 usuários, e ninguém reclamou do desempenho. Agora, não conseguimos atender nem a metade disso, com um servidor muito mais poderoso.
Você pode tentar aumentá-la para 80MB. Talvez em vez da outra alteração.
Este é um ponto em que estamos trabalhando ativamente o tempo todo.
Quando o Discourse era novo, quase todos os sites tinham um banco de dados recém-criado, então o banco de dados cabia facilmente na memória. Agora, alguns anos depois, alguns sites têm bancos de dados com mais de 100 GB e tamanhos de RAM que não chegam nem a um décimo disso.
Uma atualização próxima, nas próximas semanas, é a atualização para o PostgreSQL 13, que reduzirá pela metade o tamanho do maior objeto.
Além disso, o passo 0 para depurar seus problemas de desempenho é coletar dados com o plugin exportador Prometheus para Discourse, para que não estejamos voando às cegas.