Discussion :

[samirCA007]

Bonjour à tous,

Qui a une idée, dans postgres, de comment je peux détecter les requêtes lentes ?

J'ai de la latence dans mes applications et je ne sais pas par où je peux commencer.

Merci

[ced]

Bonjour,

La latence de vos applications peut résulter de plusieurs causes, pas nécessairement imputables à des requêtes lentes.
Il peut, par exemple, y avoir des problèmes de réseau, des problèmes de configuration du serveur...
Si vous utilisez un ORM, il peut aussi y avoir des problèmes liés aux requêtes qu'il génère (et qui surchargent le serveur).
Bref, il convient, au départ, d'essayer d'éliminer les différentes causes possibles.

Si c'est bien un problème de "requêtes lentes", une des meilleures solutions, sous PostgreSQL, est d'utiliser l'extension pg_stat_statements.
Elle a l'avantage de collecter des statistiques sur toutes les requêtes exécutées sur le serveur. Ainsi, vous pouvez détecter les requêtes qui prennent un temps moyen d'exécution que vous jugeriez trop long, mais aussi de voir si ces requêtes sont souvent exécutées ou pas.
Par ailleurs, elle permet de détecter des requêtes qui, prises isolément, ont un temps d'exécution qui vous paraîtrait acceptable, mais qui sont exécutées tellement souvent qu'elles finissent par poser problème (ce qui est le cas le plus complexe à identifier).

Une fois que vous avez identifié une ou plusieurs requêtes potentiellement problématiques, il n'y a "plus qu'à" passer par EXPLAIN (ANALYZE) pour étudier le plan d'exécution de la requête et tenter de l'optimiser. Attention, ça n'est pas non plus quelque chose d'évident.

[SQLpro]

Comme le dit très bien CED, des requêtes "lentes" cela ne veut pas dire que c'est le serveur PG qui est lent.

Par exemple l'usage du SELECT * systématique plombe dramatiquement les performances :
1) la plupart du temps aucun index ne va être utilisé, même s'il y en a beaucoup, car récupérer toutes les colonnes nécessite une double lecture INDEX + TABLE souvent plus couteuses que de lire séquentiellement toutes les lignes de la table;
2) en renvoyant toutes les colonnes, les lignes manipulées lors de l'exécution de la requête sont TRES longues… Donc, peut performantes. Sur le réseau ce sont des millions d'octets inutiles qu'il faut véhiculer entre le serveur et le client;
3) si le poste client est lent ou que les ressources sont faiblement dimensionnées (RAM en particulier), le flux entre le serveur et l'application finale, peut être ralenti par le simple fait que le poste n'absorbe pas aussi vite les octets que le serveur les envoie (attentes dit d'IO asynchrone sur le réseau).

Malheureusement, PG ne dispose pas d'outils pour mesurer finement toutes ces attentes.

Dans les grands SGBDR (SQL Server, Oracle, DB2) il existe de nombreux outils systèmes capable de mesurer toutes les temps de réponses d'une requête ou d'un lot afin d'en déduire rapidement ou ça pêche !
Exemple avec SQL Server : https://blobeater.blog/2017/01/16/lo...with-sql-2016/

A +