Maior atividade do processo idle após atualização

Olá,

Após atualizar o Discourse para a versão v2.5.0.beta4-399-gbf8085e436 (vindo de uma versão 2.4.x, usando o bootstrap via linha de comando do repositório discourse_docker no git, logo antes dos commits de atualização para o Postgres 12), notei um aumento significativo no uso de CPU do servidor (mesmo sem ninguém conectado).

O comando “top” mostra que vários processos “ruby” estão ativos com frequência. Entendi que se tratam dos workers do Sidekiq via Unicorn. Ao executar redis-cli monitor, vejo que eles fazem solicitações BRPOP bloqueantes com um tempo de espera de 2 segundos para verificar se há trabalho a ser feito. Isso resulta em uma dúzia de comandos Redis por segundo. Além disso, há estatísticas sendo atualizadas a cada 5 segundos. O comando redis-cli info stats indica que, em média, são processados entre 15 e 20 comandos por segundo.

Não sei se essa atividade pode ser responsável pelos 2-4% de utilização de CPU que observamos. Na versão anterior, o uso era inferior a 0,5%. Na época, não verifiquei as mesmas estatísticas do redis-cli.

Teria curiosidade em testar um tempo de espera maior para ver se isso ajuda, mas ainda não consegui descobrir como fazer isso.

Hmm, isso teria alguma relação com o seu trabalho, @eviltrout?

Em qual trabalho você estava pensando? Não acho que nada em que trabalhei recentemente seja provável de causar isso.

Meu erro, eu estava pensando no ember-cli

Verifique forum.example.com/sidekiq - pode haver alguns jobs de reprocessamento em segundo plano ocorrendo após a atualização.

Altamente improvável que tenha tocado no Redis. Nunca digo nunca, pois já fui queimado antes, mas suspeito que seja outra coisa :slight_smile:

Dica legal. Não vi nada alarmante lá, sem jobs rodando e nenhum com execução longa (apenas alguns acima de 100ms). O painel mostra ~1000 processados por dia, o mesmo que antes da atualização.

Provavelmente fora do tópico, mas é interessante também o gráfico de Processados nos últimos 6 meses: parece haver dois patamares (um com o dobro da altura do outro) entre os quais o sistema alterna, com semanas de intervalo. Isso não correlaciona com reinicializações (e nem atualizamos nada disso nesse período).

Existe uma maneira fácil de alterar esse timeout de 2s do BRPOP? Não encontrei no código. Isso indicaria, ao menos, se os loops de polling de trabalho são o problema.

São estas as coisas que às vezes vejo no topo:

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                     
   1024 discour+  20   0  333584 202888  21660 S   1.3   2.5   3:35.81 ruby                                                                        
   1156 discour+  20   0  715904 249416  24532 S   1.3   3.1   3:26.50 ruby                                                                        
   1178 discour+  20   0  726664 251468  24564 S   1.3   3.1   3:26.11 ruby                                                                        
   1189 discour+  20   0  714368 247912  24444 S   1.3   3.1   3:24.56 ruby                                                                        
   1200 discour+  20   0  709760 249708  24632 S   1.3   3.1   3:22.96 ruby                                                                        
   1234 discour+  20   0  713344 250288  24636 S   1.3   3.1   3:30.24 ruby                                                                        
   1167 discour+  20   0  712832 247928  24436 S   1.0   3.1   3:24.75 ruby                                                                        
 188658 me        20   0   10424   4240   3576 R   0.7   0.1   0:00.36 top                                                                         
    448 root      20   0 1748444  84900  45884 S   0.3   1.1   6:09.98 dockerd                                                                     

sem ninguém conectado…

Os 3,5 minutos de tempo de CPU acumulados para cada um são após 35 horas de atividade, com muito pouca atividade do usuário.

Também tentei usar o rbtrace, mas ele reclama:
(pid is not listening for messages, did you require “rbtrace”)
Preciso reconstruir a imagem para corrigir isso? Ou posso apenas ajustar ou reconstruir algo dentro do container?