Estou hospedando todos os meus arquivos de upload em um NAS Storage (glusterfs).
Recentemente, descobri que há um tráfego de rede enorme e constante no NAS. E rastreei isso para o discourse solicitando imagens otimizadas. Existe um job que consulta constantemente essas imagens? Por quê? E como posso desativá-lo?
Aliás, a limpeza do site de uploads nas configurações está desativada no meu fórum.
Possivelmente o preenchimento que @david adicionou para a busca da cor primária da imagem.
Eventualmente, ele terminará e retornará a um estado estável.
Precisamos percorrer todas as imagens para o preenchimento, você pode conseguir contornar forçando a cor de todas as imagens para branco ou algo assim.
Pelo que vejo,
Está funcionando em 25 imagens a cada 15 minutos. sim? isso deve ser muito insignificante. Estou vendo milhares de arquivos sendo pesquisados a cada minuto.
e também olhando a largura de banda de 6 meses atrás, vejo o mesmo comportamento. Então acho que deve ser outra coisa.
No entanto, tenho quase certeza de que está sendo feito por um job do discourse ou algo semelhante, pois quando paro o aplicativo discourse, a largura de banda desaparece. No entanto, quando apenas paro o aplicativo nginx do discourse, a largura de banda ainda permanece.
Dê uma olhada em /sidekiq, ele deve informar quais trabalhos estão em execução, certifique-se de clicar em todas as abas
Nenhum trabalho está em execução. 
. Existe algum outro trabalho que não seria listado aqui?
Ou talvez haja algo no contêiner que tenta indexar arquivos?
Toda a nossa lógica de back-end acontece em jobs do Sidekiq. Se nenhum job estiver em execução e você ainda tiver alto I/O de disco, podem ser usuários visitando seu site e imagens sendo servidas pelo nginx?
Você tem um CDN de cache na frente dos ativos estáticos?
Eu testei isso anteriormente.
Portanto, não é porque usuários estão visitando o site. Se fosse, quando eu parasse o nginx, o tráfego deveria desaparecer.
Você precisará usar as ferramentas de inspeção do Linux para ver exatamente quais PIDs e syscalls estão sendo feitos então.
@Falco @sam Acho que encontrei a causa raiz.
Primeiro reiniciei o aplicativo discourse para que o tráfego constante fosse embora. Em seguida, fui ao painel de administração e acessei a seção de relatórios em massa. Faz muito tempo que os relatórios não aparecem corretamente aqui:
Imediatamente após os relatórios expirarem, vejo o salto na largura de banda da rede. E vejo este erro nos logs de erro:
'hijack admin/reports bulk ' ainda está em execução após 90 segundos no db padrão, este processo pode precisar ser reiniciado!
O que está dando errado aqui?
O banco de dados está no mesmo armazenamento NAS?
Não, o banco de dados está no disco SSD físico.
Apenas a pasta de upload está no NAS.
Portanto, não há correlação entre eles. Voltando a
Na verdade, acho que talvez haja uma correlação. No meu ambiente de teste aqui, ele calcula o espaço utilizado.
Acho que calcular o espaço utilizado em uma pasta NAS com muitos arquivos seria muito demorado e a causa raiz de alto consumo de banda.
Estou certo?
Executar
df -Pk
df -P
du -s
Leva uma quantidade significativa de tempo no compartilhamento de rede?
estes dois foram instantâneos
df -Pk
df -P
No entanto, du -s resultou em um comportamento semelhante ao que relatei acima.
E estava rodando por cerca de 5 minutos e não terminou, e precisei terminá-lo manualmente.
Ah, entendi. O resultado desse relatório está em cache, mas acho que ele nunca termina e não pode ser armazenado em cache porque o seu compartilhamento de rede é muito lento.
Então há algo que podemos fazer para evitar isso? Por exemplo, tratá-lo como uploads s3 que não calculamos o tamanho do disco
