Então todas as alegações de que o UNICORN WORKER deve ser 2*vCPU estão erradas?
Meu servidor é Intel Xeon E5-2686 v4 @ 2.30GHz—24vCPU+32GB Ram
Quantos UNICORN WORKER preciso configurar?
8? ou 48?
Meu site tem mais de 7 mil usuários e cerca de 1 mil usuários engajados diariamente. Os usuários enviam de 3 mil a 7 mil posts por dia. Nossa comunidade tem de 120 mil a 200 mil visualizações de página por dia, incluindo rastreadores e usuários anônimos.
Isso depende de muitos fatores. Como o tamanho do seu banco de dados em comparação com a sua RAM, a proporção de tráfego logado para anônimo, se você tem plugins que mantêm sua fila Sidekiq mais ocupada, se você está executando YJIT, etc.
O que é simples é olhar os dados do MiniProfiler durante sua hora de pico e navegar pelo fórum para ver se o desempenho é pior e identificar o gargalo.
Como esta CPU é antiga, eu começaria com mais do que o número usual de workers do Unicorn, pois cada solicitação levará mais tempo do que o normal. Mas se você estiver executando PostgreSQL e Redis no mesmo servidor, não pode sacrificá-los executando muitos workers.
Tente executar 16 workers para começar e avalie o desempenho do site.
Existe uma descrição simples e amigável para humanos sobre o que os trabalhadores do Unicorn estão fazendo? A impressão que tenho é que cada solicitação de página do usuário tem que ir para um trabalhador do Unicorn para ser tratada. Se você não tiver o suficiente, o usuário terá que esperar. Se você tiver demais… bem, talvez isso lhe custe um pouco de RAM?
Eles são os servidores web da aplicação.
1 curtida
Parece que seu CPU de 10 anos está mostrando sua idade. Aumentar os trabalhadores do Unicorn permitirá que você atenda mais usuários simultaneamente, mas não tornará uma solicitação individual mais rápida.
Você pode tentar habilitar o YJIT?
3 curtidas
Com seu hardware, eu esperaria obter uma lista de login/tempo mais recente em média de cerca de 150ms no aplicativo, 80ms no SQL.
Eu começaria com 12 workers e veria como ele se comporta com isso. A melhor coisa que você pode fazer é rastrear métricas; se você quiser saber se deve adicionar mais workers, verifique se as solicitações estão sendo enfileiradas aguardando workers do aplicativo.
Você está rastreando as métricas que o próprio Discourse exporta através do exportador do Prometheus? Isso lhe dará uma boa visão de como a instância está se saindo, no geral.
Como são os números de desempenho para usuários anônimos e regulares (não administradores)?
5 curtidas
Existem muitos mega tópicos em nosso Discourse, e o maior já está na décima segunda seção.
Visualizações de resposta
1 curtida
(/para de rir, faz login no provedor de hospedagem … )
Uau, isso não é o padrão até agora??
editar: ah, claro, você pode ter compilado com um app.yml antigo e não atualizado desde então
1 curtida
Está em nossa hospedagem, mas é meio difícil torná-lo um padrão, pois as pessoas podem estar executando em cenários com restrição de RAM…
Dito isso, nossa compilação JS usa muito mais RAM do que o próprio Discourse, então você pode dizer que qualquer pessoa que possa compilar os ativos JS tem RAM de sobra 
1 curtida
Nestas imagens, quantos trabalhadores você configurou?
Eu diria que você deveria
- Aumentar um pouco os trabalhadores, pois você tem uma pequena fila
- Habilitar o YJIT, pois seu tempo de web está bem lento
Agora existem apenas 8 workers e o YJIT já está ativado.
Quantos workers devo aumentar?
A propósito, é isto que o Falco estava a observar para fazer essa recomendação:
Eu aumentaria de 8 para 12. Isso lhe dará alguma margem e deve limpar essas filas.
Esse grande pico, a propósito, é indicativo de outras requisições à espera de… algo, provavelmente um lock comum. Talvez um post de megatópico.
Se também conseguir métricas de uso do postgres, isso será útil.
megatópicos são um ponto fraco, veja Improving Instance Performance (Megatopics, Database Size and Extreme Load)
Considere dividi-los ou usar o chat em vez disso (vejo que o seu maior, com 8,9 mil respostas, é explicitamente uma sala de chat).
A cultura de discussão da nossa comunidade é megatopicos, que foi formada mesmo antes de começarmos a usar o Discourse, e o chat carece dos recursos de spoilers desfocados e detalhes ocultos.
1 curtida
Como fazer isso
Usamos o GitHub - prometheus-community/postgres_exporter: A PostgreSQL metric exporter for Prometheus, embora eu não tenha certeza se há algum guia sobre metadados para configurá-lo.
Mas, dado que você já parece ter o Prometheus configurado, parece que você sabe o que está fazendo.
agora a RAM do servidor é 16/32GB, UNICORN_WORKERS: 12, db_shared_buffers: “4096MB”
Como ainda há RAM disponível e poucas requisições web em fila, aumentei o UNICORN_WORKERS para 24. Na tarde de hoje, o servidor desligou repentinamente e, após ser reiniciado, os usuários chegaram imediatamente. Isso levou a um número muito baixo de Requisições Web Ativas e um grande número de requisições em fila. Há alguns dias, observamos que 24 UNICORN_WORKERS poderiam lidar com mais de 150 Requisições Web Ativas, mas apenas 30 Requisições Web Ativas nesta tarde. Isso ocorre porque acabamos de alterar o domínio e há muitas postagens sendo reprocessadas pelo sidekiq. Isso causou muita pressão no servidor. O que devemos fazer?
