Votre connexion réseau Redis fonctionne très mal

[markersocial]

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 :

@mcdanlj

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]

Pour faire suite à cela, je rencontre le même problème avec 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…

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 (Michael Brown)]

@markersocial

postgres plantera assez régulièrement

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]

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

@Ed_S

ma liste de diagnostics instantanés standard :

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

Peut-être que

lscpu

serait également utile

[Falco]

@markersocial

Depuis le fichier app.yml :

UNICORN_SIDEKIQS: 9
DISCOURSE_SIDEKIQ_WORKERS: 5

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

@markersocial

postgres plantera assez régulièrement

Cela ne devrait jamais arriver.

Les possibilités sont :

1. Vous êtes limité en ressources parce que soit
   a) Votre site a dépassé les ressources du serveur
   b) Vous allouez mal les ressources
2. 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.