Open VSerain opened 1 year ago
à chaque fois que c'est arriver c'était au moment du mise à jours des données DS
à chaque fois que c'est arriver c'était au moment du mise à jours des données DS
Après un peu plus d'enquête, c'est à ce moment-là que le pb était détecté, mais peut-être que la déconnexion a eu lieu plus tôt au milieu de la nuit.
J'ai regardé les logs et je ne vois vraiment pas d'erreur qui justifie la déconnexion de mongo. Si ça se reproduit je préconise de contacter scalingo
Maxime a contacté scalingo ce matin
Suivi du la discussion du 20/11
Quelle est la manipulation (commande ou depuis le dashboard) pour redémarrer les containers ? De quel containers parlez-vous car la base mongo ne peut pas être redémarrer directement.
J'ai répondu qu'en effet c'est bien le conteneur web entier que je redémarre
Vous m'avez parlé de cron où sont-ils exécuté, comment ?
Ici je ne savais pas trop quoi lui répondre, donc j'ai écris ceci (au cas ou j'ai besoin d'améliorer la réponse) :
Les CRONs sont exécutés périodiquement depuis l'app via un "Scheduler" que l'on utilise : toad-scheduler
qui utilise lui même croner
pour exécuter les CRONs répertoriés.
On peut voir dans les logs de l'application que la tâche dont vous me parlez ne semble pas pouvoir s'exécuter car visiblement il n'arrive pas à se connecter à la base de données mongo. De mon côté, je vois que la base est bien disponible, est-ce que la tâche utilise bien la variable d'env MONGO_URL ou SCALINGO_MONGO_URL pour s'y connecter ?
J'ai dis qu'on utilisait bien les variables et que ça fonctionnait avec mais que tous les lundi ça plantait
C'est pas tout à fait tous les lundis : parfois ya qu'une base qui se déconnecte (que préprod ou que prod) donc pour chacune c'est pas toujours
Ils ont eu des infos ?
Bonjour, pas de soucis. Non il n'y a pas de redémarrage des base de données. Le seul moment où il y en aurait c'est en cas de crash de cette dernière. Les problèmes de connexions pourraient être dû à des problèmes de charge sur la base. Par exemple, si la tâche cron est trop intensive. On peut voir sur la page metrics du dashboard de la base de données que cette dernière consomme de la swap. Ce qui peut être synonyme d'un manque de mémoire. Soit vous pouvez optimiser la mémoire en ajoutant des index manquants, soit passez au plan suivant. J'ai pu voir dans les logs que d'autres tâches cron tournent aussi mais n'ont pas d'erreur. Est-ce que ces dernières se connectent à la base également ? Quelles seraient les différences ?
Ce serait potentiellement lié à des CRONs trop lourd et peut-être en concurrence ?
Pas cohérent avec le timing des déconnexions. scalingo lance "une enquête approfondie".
Par ailleurs on est limite en vrai niveau mémoire, on pourrait envisager de toute façon de passer au plan supérieur là-dessus
Scalingo voit pas, ils nous conseillent de refaire le mongoClient.connect()
quand on rattrape l'erreur
https://thecodebarbarian.com/managing-connections-with-the-mongodb-node-driver.html peut-être que ça peut nous aider
Prendre les info de l'article et mettre des logs pour mieux voir les events !
https://www.mongodb.com/docs/drivers/node/v4.17/fundamentals/monitoring/cluster-monitoring/#topologyopening pour les événements + à jour
Erreur Sentry : https://sentry.incubateur.net/organizations/betagouv/issues/69167/?project=96&query=is%3Aunresolved&referrer=issue-stream&sort=freq&statsPeriod=14d