PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 19/09/2022 09:47:07

Geo-x
Membre

Nombre de requêtes simultanées

Bonjour @ tous,

Je rencontre quelques problèmes de timeout sur Postgres lors d'insertion et de mises à jour via APIs.

La volumétrie est importante (33 174 requêtes en 15 minutes avec un pic de 4718 requêtes en 1 minute).

Est-il possible de jouer sur quelques paramètres de Postgres pour accepter ces nombreux flux entrants.

Merci de votre aide.

Geo-X

Hors ligne

#2 19/09/2022 11:20:28

rjuju
Administrateur

Re : Nombre de requêtes simultanées

Bonjour,

Un pic à moins de 80 requêtes par seconde ne semble pas spécialement haut.  Impossible de répondre sans plus d'informations cependant.  D'où viennent les timeout exactement ?  Y a-t-il des erreurs remontées par postgres ?  Quels sont les capacités du serveur (RAM, cpu, disque...), et s'agit-il d'un serveur dédié pour postgres ?


Et pour finir, https://wiki.postgresql.org/wiki/Slow_Query_Questions

Hors ligne

#3 19/09/2022 15:59:35

Geo-x
Membre

Re : Nombre de requêtes simultanées

Bonjour,

1/ Les timeout viennent précisément de ces requêtes parfois trop nombreuses simultanément
2/ Etant donné que c'est une API que j'ai mis en place, je ne vois pas les erreurs
3/ 8gib de mémoire + 1 processeur Intel Xeon Platinum 8175 2vCPUs c'est du 64 bits
4/ Etant donné que c'est du cloud, pas forcément ...

Hors ligne

#4 20/09/2022 05:46:09

rjuju
Administrateur

Re : Nombre de requêtes simultanées

Les timeout viennent précisément de ces requêtes parfois trop nombreuses simultanément


Ça ne dis toujours pas d'où ils viennent.  Avez-vous mis en place statement_timeout, ou est-ce côté client ?  Quelle est la valeur du timeout, quelle est la durée de la requête quand cela arrive etc.  Et encore une fois https://wiki.postgresql.org/wiki/Slow_Query_Questions


Etant donné que c'est une API que j'ai mis en place, je ne vois pas les erreurs

Il doit bien y avoir des logs quelque part ?  Et y a-t-il des erreurs côté postgres ?


8gib de mémoire + 1 processeur Intel Xeon Platinum 8175 2vCPUs c'est du 64 bits

Ok, donc un serveur vraiment très peu puissant.

Hors ligne

#5 20/09/2022 11:34:59

Geo-x
Membre

Re : Nombre de requêtes simultanées

C'est côté client, mais j'ai quand même eu accès à certains logs et j'ai ce message en masse : LOG: unexpected EOF on client connection with an open transaction

ça veut dire que les connexions ne sont pas fermées c'est bien ça ?

Hors ligne

#6 20/09/2022 12:17:11

rjuju
Administrateur

Re : Nombre de requêtes simultanées

Oui, cela veut dire que le client a fermé la connexion sans se déconnecter explicitement.  À priori rien n'indique que le problème vienne d'une lenteur côté base de donnée, et à moins que vous ne puissiez montrer un exemple de requête lente ou autre problème côté postgres impossible de vous aider.

Hors ligne

#7 20/09/2022 13:55:29

dverite
Membre

Re : Nombre de requêtes simultanées

Geo-x a écrit :

Bonjour @ tous,

Je rencontre quelques problèmes de timeout sur Postgres lors d'insertion et de mises à jour via APIs.

La volumétrie est importante (33 174 requêtes en 15 minutes avec un pic de 4718 requêtes en 1 minute).

Est-il possible de jouer sur quelques paramètres de Postgres pour accepter ces nombreux flux entrants.

En principe on ne change pas des paramètres sans avoir au moins des hypothèses sur la cause des lenteurs, sauf si les paramètres basiques de tuning comme shared_buffers ou work_mem ne sont cohérents avec les capacités du serveur.


Très souvent on installe l'extension pg_stat_statements pour collecter les requêtes normalisées avec leurs temps d'exécution mix/max/moyen, qui  donnent des éléments concrets d'analyse.


Une autre méthode très utilisée est de mettre log_min_duration_statement au seuil de durée d'exécution que vous souhaiteriez que vos requêtes ne dépassent pas. Toutes les requêtes plus longues sortiront dans le log. Ensuite on peut analyser le log avec pgBadger.


Il est aussi recommandé d'activer log_lock_waits, qui permettra de savoir si des requêtes sont lentes parce qu'elles attendent  des verrous. Les logs produits sont aussi visibles de manière assez claire dans les rapports pgBadger. Pendant qu'on y est on ajoute souvent log_checkpoints et les logs d'autovacuum, ainsi qu'éventuellement log_temp_files.


Il y a aussi des outils de monitoring qui capturent à fréquence régulière la vue pg_stat_activity (entre autres) pour voir combien de connexions sont occupées à faire quoi. Généralement on regarde ces résultats en même temps que les métriques système d'activité CPU et disque.

Hors ligne

Pied de page des forums