Sua conexão de rede Redis está apresentando um desempenho extremamente ruim

[markersocial]

Estou recebendo consistentemente isso nos logs - com valores entre ~100k e ~1,35m - mas as leituras próximas a 100k parecem ser bastante comuns:

Sua conexão de rede Redis está com desempenho extremamente ruim. As últimas leituras de RTT foram [97069, 103986, 98459, 100762, 381617], idealmente deveriam ser < 1000. Certifique-se de que o Redis esteja em execução na mesma AZ ou datacenter que o Sidekiq. Se esses valores estiverem próximos de 100.000, isso significa que seu processo Sidekiq pode estar saturado de CPU; reduza sua concorrência e/ou veja https://github.com/mperham/sidekiq/discussions/5039

Isso indica que talvez o Redis não consiga usar CPU suficiente? Parece haver bastante espaço para CPU e RAM no próprio servidor.

Também:
Sidekiq está consumindo muita memória (usando: 3570.19M) para 'www.example.com', reiniciando

Isso está usando o aplicativo all in one app.yml com Discourse stable 3.3.2.

Do app.yml:

UNICORN_SIDEKIQS: 9
DISCOURSE_SIDEKIQ_WORKERS: 5

Adicionei esta configuração ao host também:

@mcdanlj

Configuração do Kernel

O Redis (um dos componentes chave nos quais o Discourse é construído) recomenda fortemente desativar páginas gigantes transparentes ao usar persistência em disco (o que o Discourse faz), e eu também permito o overcommit de memória.

echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
echo 'vm.overcommit_memory=1' > /etc/sysctl.d/90-vm_overcommit_memory.conf
sysctl --system

Informações do painel do Sidekiq:

Parece que o Redis não consegue ultrapassar o uso de 1024M de memória.

Se alguém tiver alguma ideia, ficarei grato!

[markersocial]

Para dar seguimento a isso, estou tendo o mesmo problema com Jobs::PostAlert:

PostAlerter job hangs/OOMs as of late

Ever since FEATURE: new watched_precedence_over_muted setting (#22252) · discourse/discourse@9cf981f · GitHub (presumably!) we’re having Sidekiq queues fill up/OOM with stuck PostAlert jobs: [image] [image] Given this commit has already had a similar regression (FIX: error when CategoryList tried to find relevant topics by lis2 · Pull Request #22339 · discourse/discourse · GitHub) it’s fairly suspect - we’ll try downgrading to a commit before the aforementioned one now though and will repor…

Com esses jobs frequentemente chegando a 15 minutos ao usar 4 sidekiqs com 5 (padrão) threads com os testes atuais. Parece que a velocidade de jobs por segundo para o Sidekiq depende principalmente de quantos desses jobs estão sendo executados simultaneamente e quantos threads estão livres para os outros jobs.

Aumentar os Sidekiqs para 6 ou mais (5 threads) aumentará a velocidade de liberação da fila, mas o postgres travará com bastante regularidade (imagino que devido a muitos jobs Jobs::PostAlert sendo executados simultaneamente).

Isso está na versão Stable 3.3.2. As alterações e correções do thread vinculado já parecem ter sido implementadas na 3.3.2, se não me engano.

[supermathie (Michael Brown)]

@markersocial

O Postgres irá travar com bastante regularidade

O Postgres nunca deveria travar e, geralmente, isso indica um bug do Postgres ou algum tipo de problema maior.

Você tem os logs?

[Ed_S]

Você reiniciou o servidor desde que fez essas alterações de configuração do kernel?

@Ed_S

minha lista de diagnósticos instantâneos padrão:

cat /etc/lsb-release
uptime
df -h /
free
vmstat 5 5
dmesg|egrep -i "memory|oom|kill"
ps auxrc

Talvez

lscpu

também seja útil

[Falco]

@markersocial

Do app.yml:

UNICORN_SIDEKIQS: 9
DISCOURSE_SIDEKIQ_WORKERS: 5

Você nunca deve aumentar UNICORN_SIDEKIQS tanto assim, apenas aumentando os workers, mas

@markersocial

o postgres irá travar com bastante regularidade

Isso nunca deveria acontecer.

As possibilidades são:

1. Você está com recursos limitados porque ou
   a) Seu site cresceu além dos recursos do servidor
   b) Você está alocando recursos incorretamente
2. Há um bug em algum lugar na pilha

Eu começaria fazendo

UNICORN_SIDEKIQS: 1
DISCOURSE_SIDEKIQ_WORKERS: 20

o que deve liberar um pouco de RAM do seu servidor.

Para mais informações, você precisará executar os jobs problemáticos em um console PostgreSQL e relatar qual é o gargalo.