La connessione di rete Redis sta funzionando estremamente male

markersocial · 12 Dicembre 2024, 10:26pm

Ottengo costantemente questo nei log, con valori compresi tra circa 100k e circa 1,35 milioni, ma le letture vicine a 100k sembrano essere abbastanza comuni:

La tua connessione di rete Redis sta funzionando in modo estremamente scadente. Le ultime letture RTT sono state [97069, 103986, 98459, 100762, 381617], idealmente dovrebbero essere < 1000. Assicurati che Redis sia in esecuzione nella stessa AZ o data center di Sidekiq. Se questi valori sono vicini a 100.000, significa che il tuo processo Sidekiq potrebbe essere saturato di CPU; riduci la concorrenza e/o consulta https://github.com/mperham/sidekiq/discussions/5039

Questo indica che forse Redis non è in grado di utilizzare abbastanza CPU? Sembra esserci molto spazio per la CPU e la RAM sul server stesso.

Inoltre:
Sidekiq sta consumando troppa memoria (utilizzando: 3570.19M) per 'www.example.com', riavvio

Questo utilizza l’app.yml all-in-one con Discourse stable 3.3.2.

Da app.yml:

UNICORN_SIDEKIQS: 9
DISCOURSE_SIDEKIQ_WORKERS: 5

Ho aggiunto anche questa configurazione all’host:

Michael K Johnson:

Configurazione del kernel

Redis (uno dei componenti chiave su cui si basa Discourse) raccomanda vivamente di disabilitare le huge page trasparenti quando si utilizza la persistenza su disco (cosa che Discourse fa), e consento anche l’overcommit della memoria.
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

Informazioni sulla dashboard di Sidekiq:

Sembra proprio che Redis non sia in grado di superare l’utilizzo di memoria di 1024M.

Se qualcuno ha qualche idea, la apprezzerei!

markersocial · 19 Dicembre 2024, 2:38pm

Per dare seguito a questo, sto riscontrando lo stesso problema con Jobs::PostAlert:

Con questi job che spesso arrivano a 15 minuti quando si utilizzano 4 sidekiq con 5 (predefiniti) thread con i test attuali. Sembra che la velocità dei job al secondo per Sidekiq dipenda principalmente da quanti di questi job vengono eseguiti contemporaneamente e quanti thread sono liberi per gli altri job.

Aumentare i Sidekiq a 6 o più (5 thread) aumenterà la velocità di svuotamento della coda, ma postgres si bloccherà abbastanza regolarmente (ipotizzo a causa di troppi job Jobs::PostAlert eseguiti contemporaneamente).

Questo è su Stable 3.3.2. Le modifiche e correzioni dal thread collegato sembrano essere già state implementate in 3.3.2, se non erro.

supermathie · 19 Dicembre 2024, 4:11pm

Postgres non dovrebbe mai bloccarsi e in genere indica un bug di postgres o una sorta di problema più grande.

Hai dei log?

Ed_S · 19 Dicembre 2024, 5:10pm

Hai riavviato il server da quando hai apportato quelle modifiche alla configurazione del kernel?

Forse

lscpu

sarebbe anche utile

Falco · 19 Dicembre 2024, 5:21pm

Non dovresti mai aumentare UNICORN_SIDEKIQS così tanto, aumentando solo i worker ma

Questo non dovrebbe mai succedere.

Le possibilità sono:

Sei limitato nelle risorse perché o
a) Il tuo sito ha superato le risorse del server
b) Stai allocando male le risorse
C’è un bug da qualche parte nello stack

Inizierei impostando

UNICORN_SIDEKIQS: 1
DISCOURSE_SIDEKIQ_WORKERS: 20

che dovrebbe liberare un po’ di RAM dal tuo server.

Per ulteriori informazioni dovrai eseguire i job in questione in una console PostgreSQL e segnalare qual è il collo di bottiglia.

markersocial · 16 Febbraio 2026, 7:10am

Mi scuso per la mia assenza e grazie per le risposte.

Credo che il problema principale della lentezza di Redis fosse che THP fosse ancora abilitato (quando pensavo il contrario):

Per i crash di PG, la soluzione principale per me è stata aggiungere questo a app.yml:

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

Con il valore impostato su db_shared_buffers + 2GB, dove db_shared_buffers è il 25% della RAM totale della macchina host.

Sovrascrivendo il valore predefinito di 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 · 16 Febbraio 2026, 12:13pm

Ho riguardato la cronologia dei tuoi post e vedo in Problema di Sidekiq molto lento… enormi quantità di notifiche utente non lette che stavi utilizzando un server con 32 core e 128 GB di RAM, con una base di utenti molto ampia e attiva. Quindi, in quel contesto, capisco perché 34G non sia un numero così grande! Per dare un contesto, tuttavia, potrebbe essere utile (e interessante) conoscere le dimensioni della tua configurazione, magari qui o anche nella tua biografia? (forse utenti attivi giornalieri e mensili, dimensioni dei backup del database, configurazione del server in termini di RAM, swap, disco, CPU). Magari anche un thread in cui condividiamo semplicemente le nostre statistiche, grandi e piccole.

Argomento		Risposte	Visualizzazioni
Redis used_memory limited to 1024mb? Support	2	142	Febbraio 16, 2026
Could sidekiq queue be reason for 500 errors? Self-hosting server-resources	31	3930	Luglio 13, 2018
Sidekiq is consuming too much memory, restarting Self-hosting	40	8840	Ottobre 13, 2020
Redis connection timed out Self-hosting	30	9612	Giugno 8, 2024
Locks up while running Sidekiq after migration Self-hosting	6	2375	Dicembre 24, 2017

La connessione di rete Redis sta funzionando estremamente male

Argomenti correlati