Bien que les choses se soient globalement bien passées, j’ai constaté par la suite des problèmes avec les processus Postgres qui s’emballaient, utilisant 100 % d’un cœur. Le nombre de processus variait cependant. J’ai essayé plusieurs choses, d’une reconstruction à des redémarrages. J’essaie actuellement un rake db:validate_indexes qui tourne déjà depuis quelques heures sans aucun retour. Je ne suis pas sûr si je l’avais déjà fait auparavant et si cela est censé se faire plus rapidement.
L’utilisation du forum fonctionne bien en gros, mais est nettement ralentie. Certaines tâches de longue durée, comme l’affichage des profils d’utilisateurs plus actifs, prennent notablement plus de temps que d’habitude.
Je suis presque sûr qu’il y a des problèmes avec la base de données, mais j’ai du mal à identifier lesquels.
Je dois dire que notre base de données est assez énorme - nous sommes à environ 150 Go après la restauration et après la création des index. En surveillant le processus de restauration, je n’ai vu aucune erreur et la création des index s’est déroulée correctement à mes yeux.
Des idées sur la façon de s’attaquer à ce problème ? Il y a actuellement 3 processus postgres - il y en avait 6 avant un redémarrage que j’ai effectué il y a quelques heures - j’ai déjà vu les 16 cœurs être utilisés après la restauration également.
EDIT : Je viens de remarquer que 3 processus sidekiq sont occupés à “indexer les catégories pour la recherche”. Cela pourrait-il être simplement la reconstruction de l’index de recherche ? Si oui, cela peut-il être résolu autrement ? Lorsque nous effectuerons la restauration du système en direct, ce sera un énorme problème si cela dégrade les performances pendant plusieurs heures, voire plusieurs jours.
Pour le moment, une seule tâche sidekiq s’exécute avec « Jobs::BackfillBadge », mais 7 processus postgres bloquent toujours constamment 100 % du CPU. Je suis vraiment curieux de savoir ce qui se passe là-bas.
Je ne sais pas si cela fait quelque chose, mais cela fait déjà plus de 30 minutes que c’est là.
J’ai mis le forum en lecture seule et redémarré la VM pour arrêter les 7 processus Postgres qui étaient “bloqués” là auparavant. Peu de temps après le redémarrage, 2 de ces processus postgres sont revenus et n’ont pas changé. Rien ne tourne dans sidekiq actuellement.
Vous ne voulez vraiment pas exécuter un VACUUM complet. Tout ce dont vous avez besoin pour retrouver les performances est un VACUUM VERBOSE ANALYZE. Vous ne pouvez pas exécuter un FULL sur un site en cours d’exécution.
Ah ! Des conseils sensés d’un expert ! J’avais donc peut-être raison de penser que 8 Go/25 % n’était pas suffisant, et même si 16 Go représentent plus de 40 %, cela pourrait quand même être une bonne suggestion parce que…
Les gars. comme dit, c’est un serveur de test - il n’y a pas de trafic dessus. Ce serveur n’est absolument pas assez bon pour une utilisation en production, mais ce n’est pas le problème ici. La question est de savoir pourquoi nous voyons des processus postgres bloqués comme ça (avec 100% d’utilisation du CPU) et ralentissant considérablement les choses. Nous faisions fonctionner le serveur de test avec une capacité inférieure même il y a quelques jours - il n’a été augmenté qu’en raison du manque d’espace disque pour une restauration.
La machine de production fonctionne avec 128 Go de RAM avec les mêmes paramètres de tampon partagé sans aucun problème - Je ne pense donc pas qu’il y ait un problème général avec ces paramètres et la taille du tampon partagé - surtout pas une machine de test privée sans trafic.
Mais bref - je vais simplement refaire la restauration et voir si quelque chose a pu mal tourner car il n’y a apparemment pas de bonne explication pour ce comportement.
Postgres