Vous n'êtes pas identifié(e).
Nous avons observé un temps de réponse de 1 à 10 pour une requête simple (select * from data limit 2000000) qui retourne 200000 enregistrements entre deux versions de postgresql 8.3 et 8.4 avec la même base de données.
1 - ancien serveur
postgresql 8.3 : Ubuntu 8.04 LTS server, : temps de réponse <2s
2 - nouveau serveur plus puissant !!!!
postgresql 8.4 : Ubuntu 10.04 LTS server : temps de réponse >20s
Idem sur station deux autres stations de travail avec Ubuntu 10.04 et postgresql 8.4
y-a-t-il une optimisation particulière pour régler ce problème ?
Est-ce un problème d'optimisation ?
Hors ligne
Il faut davantage d'informations pour vous aider:
- La requête
- La définition des tables impliquées (et leur taille)
- Un EXPLAIN ANALYZE de la requête (EXPLAIN ANALYSE ma_requête)
Marc.
Hors ligne
La table data contient 13 millions d'enregistrements,
11 champs dont 1 champ date et des integer
la requete sur cette table data :
select * from data limit 200000
Le temps est proportionnel aux nombre d'enregistrements retournés et dans un rapport de 1 à 10 toujours
explain analyse select * from data limit 200000 ne me renseigne pas beaucoup !!!
"Limit (cost=0.00..4270.96 rows=200000 width=49) (actual time=0.022..45.561 rows=200000 loops=1)"
" -> Seq Scan on data (cost=0.00..280496.44 rows=13135044 width=49) (actual time=0.021..23.217 rows=200000 loops=1)"
"Total runtime: 57.002 ms"
Hors ligne
Ok. Donc la différence de temps d'exécution est simplement due au fait qu'à certains moments, les données que vous récupérez sont en cache, et pas à d'autres, je pense.
57ms pour lire 200 000 enregistrements, on est dans le cas où les données sont en cache, probablement.
Marc.
Hors ligne
Pour affiner les tests, j'ai une fonction PL/PGSQL identique, base identiques sur ces deux versions de postgresql avec très peu
de d'enregistrements en retour (max 112 enregistrements).
La fonction balaie une première table de 600 enregistrements pour extraire toutes les variables associées au point 531 et construit
un tableau pour ces variables trouvées à partir des données de la table data.
ancien serveur :
explain analyse
select * from extrac_intervalleforlocation(531)
"Function Scan on extrac_intervalleforlocation (cost=0.00..260.00 rows=1000 width=68) (actual time=8357.165..8357.205 rows=112 loops=1)"
"Total runtime: 8357.263 ms"
nouveau serveur
select * from extrac_intervalleforlocation(531)
"Function Scan on extrac_intervalleforlocation (cost=0.00..260.00 rows=1000 width=68) (actual time=21074.153..21074.156 rows=112 loops=1)"
"Total runtime: 21074.182 ms"
Ici c'est le temps d'execution de la fonction qui est plus du double pour notre nouveau serveur en 8.4 !!!
Dernier test; passage au postgres9.1 sur nouveau serveur et lancement des mêmes tests:
- temps d'execution < 1 seconde pour le select * from data limit 200000;
- temps d'execution proche de la seconde pour le select * from extrac_intervalleforlocation(531)
Conclusion : version 8.4 pose réellement un probleme.
Hors ligne
La conclusion me semble un peu trop rapide, vu le peu de diagnostic effectué…
On n'a pas le détail de la fonction, on ne sait pas ce qui prend du temps dedans, bref, on n'a aucune information à part 'ça marche en 8.3, ça marche pas en 8.4, ça marche en 9.1'.
=> On peut avoir le code de la fonction pour commencer ? (le explain ne nous renseigne en rien, quand on a une fonction, puisque c'est une boîte noire).
Marc.
Hors ligne
Pour exactement la même requête, je n'y crois pas du tout. Il y a forcément quelque chose de différent, au niveau matériel, au niveau système d'exploitation, au niveau configuration de PostgreSQL, ou encore ailleurs.
Guillaume.
Hors ligne
Nous avons observé un temps de réponse de 1 à 10 pour une requête simple (select * from data limit 2000000) qui retourne 200000 enregistrements entre deux versions de postgresql 8.3 et 8.4 avec la même base de données.
1 - ancien serveur
postgresql 8.3 : Ubuntu 8.04 LTS server, : temps de réponse <2s2 - nouveau serveur plus puissant !!!!
postgresql 8.4 : Ubuntu 10.04 LTS server : temps de réponse >20sIdem sur station deux autres stations de travail avec Ubuntu 10.04 et postgresql 8.4
y-a-t-il une optimisation particulière pour régler ce problème ?
Est-ce un problème d'optimisation ?
Une explication possible est que par défaut les packages debian/ubuntu de postgres ont une connexion cryptée avec SSL y compris sur localhost.
Dans le cas d'un gros select * sur un réseau très rapide, a fortiori localhost, ça peut effectivement mettre 10 fois plus de temps en crypté qu'en clair pour transférer tous les résultats.
Et le temps en question ne se voit pas dans l'explain analyze.
En revanche en socket du domaine unix il n'y a jamais de cryptage, c'est précisé dans la doc de libpq.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
