Discussion :

[clavier12AZQSWX]

bonjour,

je voudrais optimiser mon serveur postgres (8.1 debian 2Go de RAM bi-xeon 5130) pour rendre l'exécution de cette requête monstrueuse plus rapide :

select id from sale_order_line where (state in ('confirmed','confirmed_wait','missed')) and (id in (27403,27405,27399,16583,27395,19018,27394,21292,20594,19019,20593,7682,27392,17994,28130,18039,27389,27380,27379,27377,27378,18020,27374,18002,27373,17878,17877,18146,27369,27367,27364,9692,27362,27360,17710,27357,27356,27355,27354,18148,27185,27352,27350,27348,3354,27345,18191,17707,27347,27343,27341,27339,27338,27334,17702)) order by id DESC limit 50

je ne peux pas intervenir sur le code de l'erp, juste sur les paramètres de psotgres voire de linux. cette requête prend 16s à donner les résultats, occupe lecpu à 100% et utilise 6% de la RAM (info obtenu sur un top en ligne de commande)

là j'ai coupé mais en fait il ya plus (10pages) d'id dans la liste...
j'a itenté d'enlever le order id mais ça change rien.

[estofilo]

Il faut avoir le EXPLAIN ANALYZE de la requête en question

[clavier12AZQSWX]

voilà les détails obtenus avec un explain analyse précédent la requête (fait dans pgadmin):

"Limit  (cost=0.00..26675.74 rows=50 width=4) (actual time=3.982..264.556 rows=50 loops=1)"
"  ->  Index Scan Backward using sale_order_line_pkey on sale_order_line  (cost=0.00..1202542.36 rows=2254 width=4) (actual time=3.977..264.454 rows=50 loops=1)"
"        Filter: ((((state)::text = 'confirmed'::text) OR ((state)::text = 'confirmed_wait'::text) OR ((state)::text = 'manquant'::text)) AND ((id = 27403) OR (id = 27405) OR (id = 27399) OR (id = 16583) OR (id = 27395) OR (id = 19018) OR (id = 27394) OR (i (..)"
"Total runtime: 309.079 ms"

[estofilo]

Apparemment ça utilise bien un index (Index Scan Backward using sale_order_line_pkey) mais surtout le temps d'exec n'est que de 0.3s et pas de 16s

[clavier12AZQSWX]

comme dit plus haut, il ya bcp (trop) d'éléments énumérés dans la partie

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

and (id in (x1,x2.x3....x25000)

j'en ai dénombré entre 23000 et 25000. la requête complète fait 10-20pages de copier collé dans la console linux !

je rappelle j'y peux rien si l'erp construit mal sa requête... où alors les développeurs n'avait pas prévu autant de donnée (25000 lignes de commandes/factures)

pour info j'ai testé la base sur une autre machine (vm s7 x64 workstation avec 1 core 3.33ghz et 1ghz de mémoire alloués) et la requête prend 3s au lieu des 15s du bi-xeon à 2Ghz.

ce gain énorme dans le passage à la VM.....normal pas normal...à réfléchir...?
Ya 6ans de techno de différence entre le core 3.3ghz du core i7-975 et le vieux core 2.0ghz du xeon 5130. ou alors c'est l'encapsulation du système de fichier dans la vm qui augmente les perfs (car moins de lecture/écriture réelles).

[estofilo]

La différence de perfs est difficile à expliquer sans regarder en détail tous les indicateurs susceptibles de faire varier les perfs et il y en beaucoup: taille de cache disque, à supposer que la table et index y soit, et si il y a des E/S disques, la quantité de bloc transférés est-elle la même et la vitesse de transfert est-elle la même?

Par ailleurs la différence d'âge des CPUs joue certainement, sans être un connaisseur du hardware, un facteur 5 entre des générations séparées de 6 ans ne parait pas délirant.