Activité de processus inactif plus élevée après la mise à niveau

Soutien Installation
1

Bonjour,
Après avoir mis à jour Discourse vers la version v2.5.0.beta4-399-gbf8085e436 (provenant d’une version 2.4.x, en utilisant le bootstrap en ligne de commande depuis le dépôt discourse_docker sur Git, juste avant les commits de mise à niveau vers Postgres 12), on observe une activité CPU nettement plus élevée sur le serveur (même lorsque personne n’est connecté).

La commande “top” indique que plusieurs processus “ruby” sont actifs assez fréquemment. J’ai compris qu’il s’agit des workers unicorn sidekiq. En exécutant redis-cli monitor, je constate qu’ils effectuent des requêtes BRPOP bloquantes avec un délai d’attente de 2 secondes pour vérifier s’il y a du travail à effectuer. Cela équivaut à une douzaine de commandes Redis par seconde. De plus, des statistiques sont mises à jour toutes les 5 secondes. La commande redis-cli info stats indique qu’en moyenne, 15 à 20 commandes sont traitées par seconde.

Je ne sais pas si cette activité peut expliquer les 2 à 4 % d’utilisation du CPU que nous observons. Avec l’ancienne version, elle était inférieure à 0,5 %. Je n’ai pas examiné les mêmes statistiques redis-cli à cette époque.

Je serais curieux de tester un délai d’attente plus long pour voir si cela aide, mais je n’ai pas encore trouvé comment procéder.

2

Hmm, cela serait-il lié à ton travail @eviltrout ?

3

De quel travail parlais-tu ? Je ne pense pas que rien de ce sur quoi j’ai travaillé récemment soit susceptible de causer cela.

4

Ma faute, je pensais à ember-cli

5

Vérifiez forum.example.com/sidekiq - il se peut que des tâches de traitement en arrière-plan soient en cours après la mise à niveau.

6

Très peu probable que cela ait touché Redis. Je ne dirai jamais jamais, car j’ai déjà été pris au piège auparavant, mais je soupçonne qu’il s’agit de quelque chose d’autre :slight_smile:

7

Super astuce. Je n’ai rien d’inquiétant vu là-dedans : aucun job en cours d’exécution et aucun avec une exécution longue (seulement quelques-uns dépassant 100 ms). Le tableau de bord indique environ 1 000 éléments traités par jour, comme avant la mise à niveau.

Hors sujet probablement, mais le graphique « Processed » sur six mois est aussi intéressant : on dirait qu’il y a deux paliers (l’un deux fois plus élevé que l’autre) entre lesquels il bascule, avec des semaines d’écart. Cela ne semble pas corréler avec les redémarrages (et nous n’avons pas mis à jour ces éléments durant cette période non plus).

Y a-t-il un moyen simple de modifier ce délai d’attente BRPOP de 2 s ? Je ne l’ai pas trouvé dans le code. Cela indiquerait au moins si les boucles de sondage des tâches sont le problème.

9

Voici ce que je vois parfois dans top :

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                     
   1024 discour+  20   0  333584 202888  21660 S   1.3   2.5   3:35.81 ruby                                                                        
   1156 discour+  20   0  715904 249416  24532 S   1.3   3.1   3:26.50 ruby                                                                        
   1178 discour+  20   0  726664 251468  24564 S   1.3   3.1   3:26.11 ruby                                                                        
   1189 discour+  20   0  714368 247912  24444 S   1.3   3.1   3:24.56 ruby                                                                        
   1200 discour+  20   0  709760 249708  24632 S   1.3   3.1   3:22.96 ruby                                                                        
   1234 discour+  20   0  713344 250288  24636 S   1.3   3.1   3:30.24 ruby                                                                        
   1167 discour+  20   0  712832 247928  24436 S   1.0   3.1   3:24.75 ruby                                                                        
 188658 me        20   0   10424   4240   3576 R   0.7   0.1   0:00.36 top                                                                         
    448 root      20   0 1748444  84900  45884 S   0.3   1.1   6:09.98 dockerd

sans aucune connexion…

Les 3,5 minutes de temps CPU cumulées chacune s’accumulent après 35 heures de fonctionnement, avec très peu d’activité utilisateur.

J’ai également essayé d’utiliser rbtrace, mais il affiche une erreur :
(pid is not listening for messages, did you require “rbtrace”)
Dois-je reconstruire l’image pour corriger cela ? Ou puis-je simplement ajuster ou reconstruire quelque chose à l’intérieur du conteneur ?