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

markersocial · Dezembro 12, 2024, 10:26pm

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:

Michael K Johnson:

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 · Dezembro 19, 2024, 2:38pm

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

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 · Dezembro 19, 2024, 4:11pm

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 · Dezembro 19, 2024, 5:10pm

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

Talvez

lscpu

também seja útil

Falco · Dezembro 19, 2024, 5:21pm

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

Isso nunca deveria acontecer.

As possibilidades são:

Você está com recursos limitados porque ou
a) Seu site cresceu além dos recursos do servidor
b) Você está alocando recursos incorretamente
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.

markersocial · Fevereiro 16, 2026, 7:10am

Peço desculpas por ter desaparecido e obrigado pelas respostas.

Acredito que o principal problema para o Redis estar lento era que o THP ainda estava ativado (quando eu pensei que não):

Para o travamento do PG, a principal solução para mim foi adicionar isto ao app.yml:

docker_args:
  - "--shm-size=34g"

Com o valor definido como db_shared_buffers + 2GB, sendo db_shared_buffers 25% da RAM total da máquina hospedeira.

Sobrescrevendo o padrão de 512m:

github.com/discourse/discourse_docker

launcher

4ae1f6914


      
               if [ -z "$SKIP_MAC_ADDRESS" ] ; then
                mac_address="--mac-address $($docker_path run $user_args -i --rm -a stdout -a stderr $image /bin/sh -c "echo $hostname | md5sum | sed 's/^\(..\)\(..\)\(..\)\(..\)\(..\).*$/02:\1:\2:\3:\4:\5/'")"
               fi
          
               if [ ! -z "$START_CMD_ONLY" ] ; then
                 docker_path="true"
               fi
          
               set -x
          
               $docker_path run --shm-size=512m $links $attach_on_run $restart_policy "${env[@]}" "${labels[@]}" -h "$hostname" \
                  -e DOCKER_HOST_IP="$docker_ip" --name $config -t "${ports[@]}" $volumes $mac_address $user_args \
                  $run_image $boot_command
          
             )
             exit 0
          
          }
          
          run_run() {
            set_template_info

github.com/discourse/discourse_docker

launcher

4ae1f6914


      
          
          }
          
          run_run() {
            set_template_info
            set_volumes
            set_links
            set_run_image
          
            unset ERR
            (exec $docker_path run --rm --shm-size=512m $user_args $links "${env[@]}" -e DOCKER_HOST_IP="$docker_ip" -i -a stdin -a stdout -a stderr $volumes $run_image \
              /bin/bash -c "$run_command") || ERR=$?
          
            if [[ $ERR > 0 ]]; then
              exit 1
            fi
          }
          
          run_bootstrap() {
            set_template_info

github.com/discourse/discourse_docker

launcher

4ae1f6914


      
              pups_command="$pups_command git pull && git checkout $pups_version &&"
            fi
            pups_command="$pups_command /pups/bin/pups --stdin"
          fi
          
          echo $pups_command
          
          declare -i BOOTSTRAP_EXITCODE
          rm -f $cidbootstrap
          
          echo "$input" | $docker_path run --shm-size=512m $user_args $links "${env[@]}" -e DOCKER_HOST_IP="$docker_ip" --cidfile "$cidbootstrap" -i -a stdin -a stdout -a stderr $volumes $image \
            /bin/bash -c "$pups_command"
          BOOTSTRAP_EXITCODE=$?
          
          CONTAINER_ID=$(cat "$cidbootstrap")
          rm -f "$cidbootstrap"
          
          # magic exit code that indicates a retry
          if [[ $BOOTSTRAP_EXITCODE -eq 77 ]]; then
            $docker_path rm "$CONTAINER_ID"
            exit 77

Ed_S · Fevereiro 16, 2026, 12:13pm

Eu olhei seu histórico de publicações e vejo em Problema muito lento do Sidekiq… números massivos de notificações de usuários não lidas que você estava executando um servidor de 32 núcleos e 128 GB, com uma base de usuários muito grande e ativa. Então, nesse contexto, eu vejo por que 34G não é um número tão grande! Para contexto, no entanto, pode ser útil (e interessante) saber o tamanho da sua configuração - possivelmente aqui ou até mesmo na sua biografia? (talvez usuários ativos diários e mensais, tamanho dos backups do banco de dados, configuração do servidor em RAM, swap, disco, CPUs.) Talvez até um tópico onde apenas compartilhamos nossas estatísticas - grandes e pequenas.

Tópico		Respostas	Visualizações
Redis used_memory limited to 1024mb? Support	2	141	16 de Fevereiro de 2026
Could sidekiq queue be reason for 500 errors? Self-hosting support server-resources	31	3927	13 de Julho de 2018
Sidekiq is consuming too much memory, restarting Self-hosting support	40	8840	13 de Outubro de 2020
Redis connection timed out Self-hosting support	30	9610	8 de Junho de 2024
Locks up while running Sidekiq after migration Self-hosting support	6	2375	24 de Dezembro de 2017

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

Tópicos relacionados