Erreur de charge extrême après la mise à jour vers 3.3.0.beta3-dev hier (sur site)

Mis à niveau vers la version 3.3.0.beta3-dev hier et j’ai également installé le plugin IA. Le plugin est actuellement activé uniquement pour les membres du personnel (5 personnes)

Mais le site entier est très lent, j’ai des erreurs de chargement extrêmes. Je n’arrive pas à comprendre d’où cela vient, la charge de mon serveur semble normale.

Y a-t-il un ou des endroits où je peux aller pour comprendre ce qui en est la cause ?

Voici ce que je vois dans le rapport d’exploration, je ne sais pas si c’est bien ou mal, ou quoi. Je n’ai pas de point de référence.

En regardant mon serveur, il semble que les processus unicorn soient très occupés

Est-ce la cause ? Ai-je besoin de plus de CPU ? Ou juste plus d’Unicorns ?

Cela fait longtemps que vous n’avez pas effectué de mise à niveau ? Il effectue peut-être un traitement d’image ou un ré-enfournement.

Vous pouvez regarder sur /sidekiq pour voir ce qu’il fait.

Les files d’attente sont vides

Je ne sais pas vraiment ce que signifie le reste.

Je ne suis pas sûr de ce qui est normal ici… Voici les spécifications de notre serveur
image

J’ai tout redémarré, tout est revenu à la normale, mais nous subissons à nouveau une charge extrême. Je n’arrive pas à déterminer d’où vient le problème. Existe-t-il des outils dans Discourse qui pourraient m’aider ?

Donc les 3 employés unicorn
image

Sont occupés… mais nous n’avons pas plus de trafic que la normale, d’après ce que je peux dire, c’est à peu près le même qu’avant. Le seul changement a été la mise à niveau vers la version 3.3.0 et l’ajout du plugin Ai, mais il n’est disponible que pour le personnel.

Les problèmes ont commencé hier 06/03

Nous avons apparemment quelques robots d’exploration supplémentaires.

Voici juste les robots d’exploration sur un mois, mais encore une fois, cela ne semble pas beaucoup plus élevé. Le site est presque inutilisable.

Toute aide serait appréciée !

Ceci est une supposition, mais la seule chose qui me frappe dans les journaux Sidekiq est que le travail affiché est NotifyMailingListSubscribers. Ce travail peut potentiellement créer beaucoup de requêtes.

De plus, voyez-vous des erreurs sur votre page Admin / Journaux / Journaux d’erreurs ?

J’ai ajouté un bloc au robot d’exploration de Facebook car ce type allait bon train
image

Cependant, j’ai remarqué que l’ajout de ralentissements / robots d’exploration ne met pas à jour mon robots.txt

mais robots.txt n’affiche pas les entrées de ralentissement, seulement les entrées de blocage.

Il y en a pas mal de celles-ci

Je vois 3 erreurs mais elles ne semblent pas liées… (bien qu’il soit difficile de le dire)

Job exception: PG::DatetimeFieldOverflow: ERROR:  timestamp out of range: \"271768-09-23 06:24:11.793040 BC\"
LINE 1: ...sers\".\"moderator\" = FALSE AND (users.created_at < '271768-09...
                                                             ^
ActionDispatch::RemoteIp::IpSpoofAttackError (IP spoofing attack?! HTTP_CLIENT_IP=\"10.10.121.119\" HTTP_X_FORWARDED_FOR=\"14.140.10.244, 14.140.10.244\")
app/controllers/topics_controller.rb:1298:in `track_visit_to_topic'
app/controllers/topics_controller.rb:169:in `show'
app/controllers/application_controller.rb:422:in `block in with_resolved_locale'
app/controllers/application_controller.rb:422:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:64:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:391:in `call'
lib/middleware/csp_script_nonce_injector.rb:12:in `call'
config/initializers/008-rack-cors.rb:14:in `call'
config/initializers/100-quiet_logger.rb:20:in `call'
config/initializers/100-silence_logger.rb:29:in `call'
lib/middleware/enforce_hostname.rb:24:in `call'
lib/middleware/request_tracker.rb:291:in `call'

Et une autre exception de job concernant le SMTP

Discourse effectue sa propre limitation de débit, il ne s’appuie pas sur robots.txt

Merci Michael,

D’autres idées sur ce que cela pourrait être ? Faire tourner plus de licornes aiderait-il ?

Est-ce que cela se fait à partir du fichier app.yml ?

Oui, cela aiderait probablement.

env:
  UNICORN_WORKERS: 8

dans le fichier app.yml fera cela.

Je recommande de récupérer les chiffres de performance à l’aide du plugin Prometheus si vous l’avez configuré, ou vous pouvez utiliser les en-têtes de performance.

L’analyse de vos journaux web devrait beaucoup aider à identifier pourquoi votre serveur est si occupé ; il semble que les robots d’exploration soient un bon point de départ.

2 « J'aime »

Bien mis à niveau vers une nouvelle instance DO, doublé la RAM et le CPU. Ajouté 8 licornes (contre 3), effectué un réindexage et un vacuum de la base de données, et je pense que nous sommes de retour en affaires !

Merci pour votre aide

3 « J'aime »

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.