Alto uso de CPU (Ruby)

Estou vendo com bastante frequência o uso elevado da CPU, geralmente em torno de 85%:

Anteriormente, estava aparecendo como unicorn.conf.r:

Isso poderia indicar que UNICORN_WORKERS está configurado muito alto/baixo?

O servidor tem 64 GB de RAM (geralmente mostra cerca de 40 GB livres) e 6 núcleos. Há 4 instâncias do Discourse no servidor, cada uma configurada com UNICORN_WORKERS: 8.

Alguma ideia ou dica sobre o que está causando isso ou o que tentar? (Um dos fóruns está em modo somente leitura e não recebe muito tráfego, ele deveria ser configurado com menos workers?)

2 curtidas

Não sei, mas aposto que você está usando muito mais workers do que seus núcleos podem oferecer?

1 curtida

Sim. Eu também sugiro diminuir o número de trabalhadores de unicórnio:

2 curtidas

Você poderia tentar reduzir os trabalhadores do unicorn.

2 curtidas

Obrigado pelas respostas a todos - não tenho certeza onde li isso agora, mas sempre pensei que deveríamos definir 2 workers por núcleo. Reduzi o número de workers agora por fórum, alocando mais para os fóruns mais movimentados e menos para os menos movimentados. Monitorarei as coisas na próxima semana e reportarei se não ajudar.

Editar: Acho que li aqui.

1 curtida

No seu caso, você não está alocando dois workers por núcleo. Você tem seis núcleos, o que significaria doze workers, mas você tem quatro instâncias, cada uma usando oito workers, totalizando 32.

4 curtidas

Sim… Ajustei para que o número total de workers não seja maior que o dobro do número de núcleos, embora eu ainda me pergunte - qual é o conselho correto/padrão, o que você disse ou o que estava no post do Nate, onde ele cita Jeff dizendo 1 worker por núcleo?

A partir dos meus próprios experimentos, 1 worker por núcleo resulta em timeouts (mas diminui a carga do servidor), mais workers resultam em melhor desempenho, mas carga maior (que no meu servidor ainda está dentro de uma faixa aceitável).

1 curtida

Veja o discourse-setup, que lida com a escalabilidade para novas instalações hoje:

# UNICORN_WORKERS: 2 * GB para 2GB ou menos, ou 2 * CPU, máximo 8
  if [ "$avail_gb" -le "2" ]
  then
    unicorn_workers=$(( 2 * $avail_gb ))
  else
    unicorn_workers=$(( 2 * $avail_cores ))
  fi
  unicorn_workers=$(( unicorn_workers < 8 ? unicorn_workers : 8 ))

Essa segunda declaração, usando o dobro do número de núcleos disponíveis, é o padrão em sistemas com mais de 2GB de RAM. Parece que seu problema é mais uma disputa entre suas instâncias (recursos do host), em vez de um problema do discourse.

2 curtidas

Estou vendo a mesma coisa depois da minha última atualização, que foi um dia depois do OP, então não acho que isso tenha a ver com o número de workers do unicorn. O processo unicorn.conf.r* é suspeito, porque a postagem original deste tópico é o único resultado para esse termo em toda a web. Acredito que unicorn.conf.rb seria mais normal.

O aumento aconteceu exatamente na minha última atualização, 4 dias atrás. Note que o OP postou 5 dias atrás. Algo mudou no Discourse.

Usei o mesmo número de workers do unicorn na mesma instância por vários anos, e não mudei nada - apenas reconstruí para 3.4.0.beta4-dev.

1 curtida

Para que conste, não há trabalhos de longa duração ou com falha no sidekiq.

1 curtida

Reconstruí sem plugins (exceto o gerenciador do docker) e o problema persiste, então a culpa não é de nenhum plugin.

Alguma pista aqui?

Acabei de atualizar para o Discourse mais recente e não vi mais unicorn.conf.r* (agora qualquer coisa em torno da marca de 80% de CPU é apenas ruby, embora pareça menos frequente). As cargas estão em torno do mesmo (embora menores do que estavam depois que fiz esses ajustes de worker).

Você atualizou para a versão mais recente? Que tipo de hardware você tem e quão ocupado está o seu fórum?

Sim, estou na 3.4.0.beta4-dev. Foi isso que iniciou o alto uso de CPU. Nada mais mudou.

8 GB de RAM, 2 vCPUs, SSD de 160 GB com bastante espaço.

Postei o uso de CPU acima para o meu site de produção, que tem cerca de 30 usuários online por vez. Mas tenho um site de teste com o mesmo problema e não há absolutamente nenhum tráfego nem plugins lá. Uso de CPU antes e depois da atualização (os picos são backups diários):

1 curtida

Não tenho certeza se nossas situações estão relacionadas, Mark. Acho que no meu caso, o que Stephen disse teve um grande papel:

Recentemente, movi outras duas instâncias para o mesmo servidor e, na verdade, tinha esquecido que os workers do unicorn estavam definidos como 8 porque anteriormente estávamos em um servidor com mais núcleos (mas ele tinha seus próprios problemas, por isso voltamos para um Xeon que tinha menos núcleos, mas tinha um desempenho melhor no geral).

Então, o que descobri foi que reduzir os workers do unicorn neste servidor reduziu a carga, mas começou a nos dar timeouts; aumentá-los erradicou os timeouts, mas resultou em uma carga maior - embora ainda dentro de uma faixa aceitável. Acho que poderia aumentar os workers e ainda poderíamos lidar com a carga aumentada, mas o que temos agora é bom por enquanto.

Dito isso, movi as instâncias para o mesmo servidor e ele estava funcionando dentro do que eu esperava (então a carga aumentou, mas não muito) e parecia que uma atualização resultou em cargas mais altas… no entanto, não posso ter certeza disso, e temos que ter em mente que, de tempos em tempos, com o Discourse ganhando mais recursos, ele pode exigir hardware mais poderoso ou resultar em, às vezes, parecer ‘mais lento’ (tive algumas instâncias do Discourse em versões antigas e elas pareciam notavelmente mais rápidas - embora, é claro, elas não tivessem todos os recursos das versões mais novas).

Dito isso também, acho que as cargas diminuíram um pouco desde a última atualização do Discourse (com PG 15).

Não tenho certeza do que sugerir para você, Mark - talvez brincar com os workers e algumas outras configurações também? Como db_shared_buffers e db_work_mem? Talvez iniciar um tópico dedicado do tipo “Uso alto de CPU após atualização - minha instância precisa de ajustes de desempenho?” Ou algo assim :slight_smile:

1 curtida

Fiz o upgrade esta noite e imediatamente notei uma diferença no uso da CPU no meu site. Aqui está um gráfico de antes, durante e depois do upgrade. Isso representa uma duração de uma hora.

Instalação padrão do Discourse em contêiner único rodando em um DO - 8 GB de RAM, 2 vCPUs e SSD de 100 GB com bastante espaço.

Veremos como ficará após 12 horas.

4 curtidas

Aqui estão os resultados após 15 horas da atualização. A porcentagem de uso da CPU aumentou drasticamente em 3X. O Fator de Carga aumentou em 4x.

Min Avg. Pré-Atualização Pós-Atualização
5 .11 .4
15 .10 .45

Visão de 24 horas:


Java é o principal uso da CPU. Algo mudou drasticamente na última atualização.

Quais informações a equipe do Discourse precisa para solucionar problemas?
Este tópico deve ser movido para um Bug?

2 curtidas

Então, parece que meu problema não foram os trabalhadores do unicórnio, afinal - após a atualização de @sam seguindo o thread de @LotusJeff, as cargas do servidor voltaram ao que eram (menos da metade do que haviam aumentado)…

4 curtidas

Isso também corrigiu meu problema.

1 curtida

Eu provavelmente não teria notado se não estivesse de olho no servidor depois de ter movido recentemente os outros dois fóruns nele - me pergunto quantas pessoas isso afetou sem que elas percebessem?

A equipe do Discourse tem medidas em vigor para alertá-los sobre problemas como este? Talvez um programa voluntário que os administradores possam configurar para tópicos específicos, por exemplo, “Enviar cargas do servidor para o Discourse dentro de XX horas/dias/semanas antes/depois de uma atualização”? Ou melhor ainda, rastrear isso localmente e, em seguida, alertar os administradores quando aumentos de carga do servidor forem notados após as atualizações - que podemos então postar aqui, se necessário.

1 curtida

Eu provavelmente não teria notado o impacto, mas estou monitorando o servidor de perto porque migramos para o Discourse há cerca de 2 semanas. Estou ocupado fazendo várias validações pós-migração (execução de backup, etc.). Depois de alguns meses, eu nunca teria notado o impacto.

Eu esperaria que o Discourse tivesse um teste de carga diário em execução. Em minha vida passada, eu tinha um servidor que era reconstruído diariamente com código commitado. Ele tinha usuários simulados usando o servidor o dia todo. Medimos métricas de desempenho chave da perspectiva do usuário e da perspectiva do servidor. Isso nos permitiu detectar proativamente vazamentos de memória, código ineficiente e alterações inesperadas na experiência do usuário.

Ainda tenho que dar os parabéns a Sam e à equipe. Vindo da terra do phpBB, onde algo assim levaria décadas para ser resolvido e remediado, achei a resposta rápida fantástica. (Mesmo que isso significasse ficar acordado até as 2 da manhã no horário do CT em comparação com o horário de Sydney.)

2 curtidas