Vous n'êtes pas identifié(e).
Pages : 1
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
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
Julien.
https://rjuju.github.io/
Hors ligne
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
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.
Julien.
https://rjuju.github.io/
Hors ligne
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
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.
Julien.
https://rjuju.github.io/
Hors ligne
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.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Pages : 1
