Votre connexion réseau Redis fonctionne très mal

markersocial · Décembre 12, 2024, 10:26

Je reçois constamment ceci dans les journaux - avec des valeurs comprises entre ~100k et ~1.35m - mais les lectures proches de 100k semblent assez courantes :

Votre connexion réseau Redis est extrêmement lente. Les dernières lectures RTT étaient [97069, 103986, 98459, 100762, 381617], idéalement elles devraient être < 1000. Assurez-vous que Redis s'exécute dans la même zone de disponibilité ou centre de données que Sidekiq. Si ces valeurs sont proches de 100 000, cela signifie que votre processus Sidekiq peut être saturé en CPU ; réduisez votre concurrence et/ou consultez https://github.com/mperham/sidekiq/discussions/5039

Cela indique peut-être que Redis n’est pas en mesure d’utiliser suffisamment de CPU ? Il semble y avoir beaucoup de marge pour le CPU et la RAM sur le serveur lui-même cependant.

Aussi :
Sidekiq consomme trop de mémoire (utilisant : 3570.19M) pour 'www.example.com', redémarrage

Ceci utilise l’application tout-en-un app.yml avec Discourse stable 3.3.2.

Depuis app.yml :

UNICORN_SIDEKIQS: 9
DISCOURSE_SIDEKIQ_WORKERS: 5

J’ai également ajouté cette configuration à l’hôte :

Michael K Johnson:

Configuration du noyau

Redis (l’un des composants clés sur lesquels Discourse est construit) recommande fortement de désactiver les pages transparentes volumineuses lors de l’utilisation de la persistance sur disque (ce que fait Discourse), et j’autorise également le sur-allocation de mémoire.
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

Informations du tableau de bord Sidekiq :

Il semble en effet que Redis ne soit pas en mesure de dépasser 1024M d’utilisation de mémoire.

Si quelqu’un a des idées, j’apprécierais !

markersocial · Décembre 19, 2024, 2:38

Pour faire suite à cela, je rencontre le même problème avec Jobs::PostAlert :

Avec ces tâches qui durent souvent jusqu’à 15 minutes lorsque l’on utilise 4 Sidekiqs avec 5 threads (par défaut) lors des tests actuels. Il semble que la vitesse des tâches par seconde pour Sidekiq dépende principalement du nombre de ces tâches exécutées simultanément et du nombre de threads disponibles pour les autres tâches.

Augmenter le nombre de Sidekiqs à 6 ou plus (5 threads) augmentera la vitesse de traitement de la file d’attente, mais postgres plantera assez régulièrement (je suppose à cause d’un trop grand nombre de tâches Jobs::PostAlert exécutées simultanément).

Ceci est sur Stable 3.3.2. Les changements et corrections du fil de discussion lié semblent déjà implémentés dans la version 3.3.2, si je ne me trompe pas.

supermathie · Décembre 19, 2024, 4:11

Postgres ne devrait jamais planter et cela indique généralement un bug de postgres ou une sorte de problème plus important.

Avez-vous des journaux ?

Ed_S · Décembre 19, 2024, 5:10

Avez-vous redémarré le serveur depuis que vous avez effectué ces modifications de configuration du noyau ?

Peut-être que

lscpu

serait également utile

Falco · Décembre 19, 2024, 5:21

Vous ne devriez jamais augmenter UNICORN_SIDEKIQS à ce point, mais seulement augmenter les workers.

Cela ne devrait jamais arriver.

Les possibilités sont :

Vous êtes limité en ressources parce que soit
a) Votre site a dépassé les ressources du serveur
b) Vous allouez mal les ressources
Il y a un bug quelque part dans la pile

Je commencerais par faire

UNICORN_SIDEKIQS: 1
DISCOURSE_SIDEKIQ_WORKERS: 20

ce qui devrait libérer de la RAM de votre serveur.

Pour plus d’informations, vous devrez exécuter les tâches problématiques dans une console PostgreSQL et signaler quel est le goulot d’étranglement.

markersocial · Février 16, 2026, 7:10

Veuillez m’excuser pour ma disparition et merci pour vos réponses.

Je crois que le principal problème de lenteur de Redis était que THP était toujours activé (alors que je pensais le contraire) :

Pour les plantages de PG, la principale solution pour moi a été d’ajouter ceci à l’app.yml :

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

Avec la valeur définie sur db_shared_buffers + 2GB, db_shared_buffers étant 25% de la RAM totale de l’hôte.

Remplacement de la valeur par défaut 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 · Février 16, 2026, 12:13

J’ai examiné votre historique de publications et je vois dans Problème Sidekiq très lent… un nombre énorme de notifications utilisateur non lues que vous utilisiez un serveur de 32 cœurs avec 128 Go de RAM, avec une base d’utilisateurs très importante et active. Dans ce contexte, je comprends pourquoi 34 Go n’est pas un chiffre si énorme ! Pour information, cependant, il pourrait être utile (et intéressant) de connaître la taille de votre installation - peut-être ici ou même dans votre biographie ? (peut-être les utilisateurs actifs quotidiens et mensuels, la taille des sauvegardes de la base de données, la configuration du serveur en RAM, swap, disque, CPU.) Peut-être même un fil de discussion où nous partageons simplement nos statistiques - grandes et petites.

Sujet		Réponses	Vues
Redis used_memory limited to 1024mb? Support	2	142	Février 16, 2026
Could sidekiq queue be reason for 500 errors? Self-hosting server-resources	31	3928	Juillet 13, 2018
Sidekiq is consuming too much memory, restarting Self-hosting	40	8840	Octobre 13, 2020
Redis connection timed out Self-hosting	30	9611	Juin 8, 2024
Locks up while running Sidekiq after migration Self-hosting	6	2375	Décembre 24, 2017

Votre connexion réseau Redis fonctionne très mal

Sujets connexes