Les pods app et form ont pas mal de restarts, apparemment parce que la connexion à la DB se ferme. Aucune erreur côté DB à part des "connection reset by peer".
Une piste, sur les périodes de charge il y a beaucoup de connexions ouvertes à la DB :
Il n'y a qu'un pod app et un pod form. Chacun utilise Prisma pour l'intégralité de ses opérations DB, et Prisma recommande un pool par défaut de 5 connexions pour une appli disposant d'un seul CPU (cas relativement maximal chez nous).
Les pods
app
etform
ont pas mal de restarts, apparemment parce que la connexion à la DB se ferme. Aucune erreur côté DB à part des "connection reset by peer".Une piste, sur les périodes de charge il y a beaucoup de connexions ouvertes à la DB :
Il n'y a qu'un pod
app
et un podform
. Chacun utilise Prisma pour l'intégralité de ses opérations DB, et Prisma recommande un pool par défaut de 5 connexions pour une appli disposant d'un seul CPU (cas relativement maximal chez nous).Suite à cette discussion, j'ai confirmé avec Yoan que les clients Prisma ne sont pas bien factorisés dans le code : https://mattermost.fabrique.social.gouv.fr/default/pl/9okecbbru7bj8nnzdteq3bjoac, contrairement à la recommendation Prisma : https://www.prisma.io/docs/orm/prisma-client/setup-and-configuration/instantiate-prisma-client
Une PR est donc en préparation pour mieux partager un unique client Prisma dans le code : https://github.com/SocialGouv/enfants-du-spectacle/pull/633