Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 21/10/2013 09:57:33
- Blogger
- Membre
Optimisation serveur
Bonjour,
Je recherche le moyen d'optimiser le serveur PostgrSql 9.1 de notre entreprise.
J'ai tracée une requête qui fait:
- Un select DISTINCT dans 420 champs, tous les champs sont renommés (AS)
- Sur 28 tables (3 inner join, 24 left outer join)
- 1 Where (table.id = 1234567)
- 2 Order by (table.date1 ASC, table.date2 DESC)
Le temps moyen de cette requête est de 1200 MS et me retourne 3 lignes.
Config du serveur:
- Serveur virtuel sur une infra VMware
- 2 vcpu
- 4 Go de ram
- Debian 64bit 7.1
Pour le disque, un test avec hdparm -tT me donne une moyenne de:
- Timing cached reads: 8502 MB in 2.00 seconds = 4254.42 MB/sec
- Timing buffered disk reads: 222 MB in 3.02 seconds = 73.46 MB/sec
J'ai essayé 3 config différentes avec pgtune:DW, Web, OLTP => Le temps de la requête reste à 1200 MS
J'ai modifier le kernel.shmmax à 1Go, 2Go => Temps toujours à 1200 MS
J'ai testé avec pgbench, avec les 3 config pgtune, les résultats sont des moyennes de plusieurs tests:
- Init: pgbench -i -s 50
- Test: pgbench -c 50 -t 100 => include connexion: 1272.777076, exclude connexion: 1327.188149
- Test: pgbench -c 50 -T 60 => inc: 1182.219421, ex: 1186.106338
- Test: pgbench -c 50 -S -T 60 => 8264.884976, 8294.43543
Voilà les tests que j'ai fais.
1) Première question: Avec ces chiffres, la performance global du serveur est-elle bonne? Voyez-vous une anomalie?
2) Le temps de 1200 MS pour ce genre de requêtes est-il normal/standard? Ou vraiment trop long?
3) Et le but de mon sujet: Comment améliorer ce temps de réponse?
Merci d'avance,
Blogger
Dernière modification par Blogger (21/10/2013 10:25:07)
Hors ligne
#2 21/10/2013 10:31:40
- Blogger
- Membre
Re : Optimisation serveur
Je viens de lire un article qui dit que le DISTINCT dans un SELECT est pas très performant => http://blog.pilotsystems.net/2011/aout/ … t-distinct
J'ai donc viré le DISTINCT de la requête => Résultat très surprenant d'une moyenne de 50ms!!!?? Je descend même à 30ms.
Si je remet le DISTINCT je remonte direct à 1200ms....
La solution première serait d'enlever le DISTINCT de la requête, mais ce n'est pas moi qui à fait l'application, il faudrait revoir le modèle de données?
Merci
Hors ligne
#3 21/10/2013 10:39:37
- rjuju
- Administrateur
Re : Optimisation serveur
Bonjour,
sans plus de détail difficile de vous aider.
1) Je trouve vos chiffres hdparm plutôt bas, mais je ne sais pas quelle est la configuration matérielle utilisée. Pour information, j'ai environ le double avec un disque dur mécanique standard sur mon portable. De toutes façons, l'utilisation de disques SATA est généralement à proscrire sur un serveur de base de données.
2) Impossible de vous répondre sans la volumétrie des tables et le plan d'exécution. Un distinct sur 420 champs semble également un peu étonnant.
3) Pour améliorer le temps de réponse, il faut trouver le point de contention, ce qui n'est pas possible avec ce que vous avez fourni.
Julien.
https://rjuju.github.io/
Hors ligne
#4 21/10/2013 12:40:29
- Blogger
- Membre
Re : Optimisation serveur
Bonjour,
Merci pour votre réponse.
1) Les disques sont sur un SAN de type EMC VNX, je crois qu'il y a des disques dur classique et du SSD, faudrait pouvoir tester sur le SSD.
2.1) La taille totale de la base est de 140mb, la table la plus grande fait 8.8Mb
2.2) Le plan d’exécution? C'est à dire faire un EXPLAIN devant le SELECT?
3) Quelles informations avoir pour "localiser" ce point de contention?
Le fait des mettre des DISTINCT n'est pas une solution de facilité afin de combler les problèmes du modèle de données?
J'ai regarder les traces des requêtes, pratiquement toutes les requêtes font des distinct...je trouve ça bizarre.
Merci
Hors ligne
#5 21/10/2013 15:36:36
- kenrio
- Membre
Re : Optimisation serveur
Bonjour,
sans plus de détail difficile de vous aider.
1) Je trouve vos chiffres hdparm plutôt bas, mais je ne sais pas quelle est la configuration matérielle utilisée. Pour information, j'ai environ le double avec un disque dur mécanique standard sur mon portable. De toutes façons, l'utilisation de disques SATA est généralement à proscrire sur un serveur de base de données.
le sata est (le sas reste cher) la norme pour un serveur de base, pour de "petits" serveurs c'est bien suffisant.
dire que c'est a proscrire je trouve ça un peu abusé en soit.
2.2) Le plan d’exécution? C'est à dire faire un EXPLAIN devant le SELECT?
explain analyse select ......
et mettez le résultat ici
Dernière modification par kenrio (21/10/2013 15:37:57)
Hors ligne
#6 22/10/2013 15:51:53
- Blogger
- Membre
Re : Optimisation serveur
Bonjour,
Voici le résultat, j'ai changer le nom des champs, question confidentiel:
"QUERY PLAN"
"Unique (cost=288.96..313.17 rows=23 width=11358) (actual time=3.267..3.301 rows=3 loops=1)"
" -> Sort (cost=288.96..289.02 rows=23 width=11358) (actual time=3.266..3.266 rows=3 loops=1)"
" Sort Key: ubqknswj_.frbs_fwm, mnyjdetu_.frbs, kxvjqyus_.ovzw, lxubozfy_.ovzw, fyevhapc_.ovzw, wdcjrgzu_.ovzw, butwxadf_.ovzw, ubqknswj_.ovzw, fibtujpk_.ovzw, ajkqehut_.ovzw, mwsbkjag_.ovzw, cupsgrax_.ovzw, tszvlieo_.ovzw, bpcafleg_.ovzw, dysahzgm_.ovzw, jcpizqwg_.ovzw, gudancsq_.ovzw, hnilvzfm_.ovzw, mnyjdetu_.ovzw, fvzojhdy_.ovzw, ytxhsgnr_.ovzw, qvfkanxz_.ovzw, xvlabuyq_.ovzw, awslirdk_.ovzw, xoaqhysu_.ovzw, mptanxfe_.ovzw, rqtlogzs_.ovzw, fjlxvpsa_.ovzw, ytlvcqzg_.dihc, ytlvcqzg_.dbcg, ytlvcqzg_.afjh, ytlvcqzg_.frbs_fwm, ytlvcqzg_.frbs_to, ytlvcqzg_.ebmd, ytlvcqzg_.doeh, ytlvcqzg_.yrcf, ytlvcqzg_.fcvs, kxvjqyus_.qbhj, kxvjqyus_.heyn, kxvjqyus_.slva, kxvjqyus_.iljq, kxvjqyus_.igvd, kxvjqyus_.iarp, kxvjqyus_.sngr, kxvjqyus_.xsku, kxvjqyus_.siqa, kxvjqyus_.vbne, kxvjqyus_.dyjz, kxvjqyus_.qenk, kxvjqyus_.rvly, kxvjqyus_.miks, kxvjqyus_.jcxh, kxvjqyus_.vgsr, kxvjqyus_.fkyt, kxvjqyus_.aujx, kxvjqyus_.lgpr, kxvjqyus_.baud, kxvjqyus_.rwnf, kxvjqyus_.rcub, kxvjqyus_.qdig, kxvjqyus_.xpgf, kxvjqyus_.dtla, kxvjqyus_.xknm, kxvjqyus_.yegw, kxvjqyus_.gunq, kxvjqyus_.mbik, kxvjqyus_.idas, kxvjqyus_.aiyc, kxvjqyus_.bmed, kxvjqyus_.tudp, kxvjqyus_.myri, kxvjqyus_.vadp, lxubozfy_.alsy, lxubozfy_.muvd, lxubozfy_.qryb, lxubozfy_.ihgr, lxubozfy_.vodq, lxubozfy_.jmnq, fyevhapc_.ndzp, fyevhapc_.ndzp_tr, fyevhapc_.kspe, fyevhapc_.bayh, fyevhapc_.qwca, fyevhapc_.dihc, fyevhapc_.dbcg, fyevhapc_.sulz, fyevhapc_.frbs_fwm, fyevhapc_.frbs_to, fyevhapc_.neql, fyevhapc_.jwyr, fyevhapc_.dpbr, fyevhapc_.rwvi, fyevhapc_.enoi, fyevhapc_.tnpc, fyevhapc_.nvxg, fyevhapc_.nvxg_tr, fyevhapc_.omly, wdcjrgzu_.xayf, wdcjrgzu_.lihd, butwxadf_.ndzp, butwxadf_.ndzp_tr, butwxadf_.kspe, butwxadf_.alpc, butwxadf_.bayh, butwxadf_.qwca, butwxadf_.dihc, butwxadf_.dbcg, butwxadf_.sulz, butwxadf_.frbs_fwm, butwxadf_.frbs_to, butwxadf_.neql, butwxadf_.jwyr, butwxadf_.dpbr, butwxadf_.rwvi, butwxadf_.enoi, butwxadf_.tnpc, butwxadf_.nvxg, butwxadf_.nvxg_tr, butwxadf_.omly, ubqknswj_.dihc, ubqknswj_.dbcg, ubqknswj_.afjh, ubqknswj_.frbs_to, ubqknswj_.ebmd, ubqknswj_.doeh, ubqknswj_.yrcf, ubqknswj_.ytbs, ubqknswj_.fcvs, ubqknswj_.jtug, fibtujpk_.ovzl, fibtujpk_.fbit, fibtujpk_.zosr, fibtujpk_.gyzu, fibtujpk_.tpwn, fibtujpk_.oefk, fibtujpk_.hupq, fibtujpk_.utar, fibtujpk_.dlph, fibtujpk_.fpxe, ajkqehut_.jiaw, ajkqehut_.dklx, ajkqehut_.jpdq, ajkqehut_.nylb, ajkqehut_.rcjq, ajkqehut_.xejh, ajkqehut_.dwou, ajkqehut_.tbxm, ajkqehut_.erjd, ajkqehut_.neql, ajkqehut_.hbns, ajkqehut_.kdhj, ajkqehut_.pkqa, ajkqehut_.zbtn, ajkqehut_.tcxy, ajkqehut_.imfz, ajkqehut_.qvgn, ajkqehut_.yuvq, ajkqehut_.yuvq_ascfvr, ajkqehut_.ognf, ajkqehut_.rapy, ajkqehut_.parq, ajkqehut_.wspa, ajkqehut_.ceat, ajkqehut_.mvql, ajkqehut_.vpzw, ajkqehut_.ciwp, ajkqehut_.enoi, ajkqehut_.jtug, mwsbkjag_.jiaw, mwsbkjag_.ovzl, mwsbkjag_.cbmr, mwsbkjag_.bgfv, mwsbkjag_.kefm, mwsbkjag_.rjhl, mwsbkjag_.zosr, mwsbkjag_.qjem, mwsbkjag_.akpo, mwsbkjag_.yuvq, mwsbkjag_.yuvq_ascfvr, mwsbkjag_.gyzu, mwsbkjag_.tpwn, mwsbkjag_.tadf, mwsbkjag_.swoi, mwsbkjag_.oefk, mwsbkjag_.ozyr, mwsbkjag_.yxmn, mwsbkjag_.nlrg, mwsbkjag_.nfhc, mwsbkjag_.ewxg, mwsbkjag_.kxqt, mwsbkjag_.lfui, mwsbkjag_.yjnq, mwsbkjag_.lihd, mwsbkjag_.becq, mwsbkjag_.bjyo, mwsbkjag_.ezrj, mwsbkjag_.usdq, mwsbkjag_.xfmu, mwsbkjag_.jnks, mwsbkjag_.fpxe, cupsgrax_.cbmr, cupsgrax_.kefm, cupsgrax_.rjhl, cupsgrax_.akpo, cupsgrax_.yuvq, cupsgrax_.yuvq_ascfvr, cupsgrax_.gyzu, cupsgrax_.tadf, cupsgrax_.oefk, cupsgrax_.nfhc, cupsgrax_.wspa, cupsgrax_.bjyo, cupsgrax_.shwy, cupsgrax_.xfmu, cupsgrax_.jnks, tszvlieo_.izkp, tszvlieo_.vgsr, tszvlieo_.foea, tszvlieo_.kdpo, tszvlieo_.wblf, tszvlieo_.tjwk, tszvlieo_.xtdf, tszvlieo_.jqzu, tszvlieo_.xswi, tszvlieo_.psjb, tszvlieo_.qlho, tszvlieo_.rebs, tszvlieo_.geap, tszvlieo_.roql, tszvlieo_.vonj, tszvlieo_.ztul, tszvlieo_.uamn, tszvlieo_.kayo, tszvlieo_.phlo, tszvlieo_.zmsw, bpcafleg_.alsy, bpcafleg_.muvd, bpcafleg_.qryb, bpcafleg_.ihgr, bpcafleg_.vodq, bpcafleg_.jmnq, dysahzgm_.jzxe, dysahzgm_.jiaw, dysahzgm_.tnkl, dysahzgm_.qczy, dysahzgm_.dbnw, dysahzgm_.lyiw, dysahzgm_.fyet, dysahzgm_.zrqe, dysahzgm_.xwre, dysahzgm_.ozng, dysahzgm_.ozng_wlmdqp, dysahzgm_.xiog, dysahzgm_.qulm, dysahzgm_.xblq, dysahzgm_.gftv, dysahzgm_.mubx, dysahzgm_.nusd, dysahzgm_.fnzm, dysahzgm_.jage, dysahzgm_.fren, dysahzgm_.sepk, dysahzgm_.wehx, dysahzgm_.tpvu, jcpizqwg_.biam, jcpizqwg_.xwre, jcpizqwg_.fzlc, jcpizqwg_.tadf, jcpizqwg_.nfhc, jcpizqwg_.qryb, jcpizqwg_.gjtb, jcpizqwg_.kphc, gudancsq_.sycr, gudancsq_.coeb, gudancsq_.yuvq, gudancsq_.zumy, gudancsq_.ujgt, gudancsq_.tqid, gudancsq_.nklz, gudancsq_.hwxy, hnilvzfm_.jiaw, hnilvzfm_.ywsb, hnilvzfm_.cqmw, hnilvzfm_.wbfj, hnilvzfm_.slxh, hnilvzfm_.ibhn, hnilvzfm_.qmhg, hnilvzfm_.fxnd, hnilvzfm_.jnks_fr, mnyjdetu_.ynib, mnyjdetu_.mxoi, mnyjdetu_.lear, fvzojhdy_.eliu, fvzojhdy_.xmbt, fvzojhdy_.lzbv, fvzojhdy_.lzbv_lmqpd, ytxhsgnr_.jiaw, ytxhsgnr_.yxpv, ytxhsgnr_.lyiw, ytxhsgnr_.pylh, ytxhsgnr_.ynibs, ytxhsgnr_.dwcv, ytxhsgnr_.dwcv_lmqpd, ytxhsgnr_.lwyf, ytxhsgnr_.fxcz, ytxhsgnr_.fxcz_tph, ytxhsgnr_.efwn, ytxhsgnr_.eoai, ytxhsgnr_.vxid, ytxhsgnr_.eusd, ytxhsgnr_.eusd_abrev, ytxhsgnr_.rysz, ytxhsgnr_.snhl, ytxhsgnr_.nivt, ytxhsgnr_.nsug, ytxhsgnr_.sxzj, ytxhsgnr_.bgqu, ytxhsgnr_.rfyt, ytxhsgnr_.myhz, ytxhsgnr_.gfpk, ytxhsgnr_.punl, ytxhsgnr_.yjcr, ytxhsgnr_.vulo, ytxhsgnr_.ugnj, ytxhsgnr_.aokb, ytxhsgnr_.xwtz, ytxhsgnr_.tlyh, ytxhsgnr_.esgd, ytxhsgnr_.vxgw, ytxhsgnr_.tkou, ytxhsgnr_.wirh, ytxhsgnr_.xulf, ytxhsgnr_.hxtz, ytxhsgnr_.ikoz, ytxhsgnr_.axpl, ytxhsgnr_.pdms, ytxhsgnr_.qryb, ytxhsgnr_.qryb_comp, ytxhsgnr_.gomj, ytxhsgnr_.efoq, ytxhsgnr_.sour, ytxhsgnr_.mjah, ytxhsgnr_.fulq, ytxhsgnr_.tals, ytxhsgnr_.lzbv_lmqpd, ytxhsgnr_.fitu, ytxhsgnr_.fitu_ertdee, ytxhsgnr_.fitu_sxc_lpf, ytxhsgnr_.bgdk, ytxhsgnr_.kqlr, ytxhsgnr_.isyz, ytxhsgnr_.ixzp, qvfkanxz_.jiaw, qvfkanxz_.vhoc, qvfkanxz_.rtxw, xvlabuyq_.jiaw, xvlabuyq_.vmzd, xvlabuyq_.ywsb, xvlabuyq_.ojdl, xvlabuyq_.qryb, iwuvafgk_.xmbt, iwuvafgk_.yzex, awslirdk_.jiaw, awslirdk_.ygau, awslirdk_.tfna, awslirdk_.grtk, awslirdk_.ezoh, awslirdk_.jmnq, xoaqhysu_.sycr, xoaqhysu_.coeb, xoaqhysu_.yuvq, xoaqhysu_.zumy, xoaqhysu_.ujgt, xoaqhysu_.tqid, xoaqhysu_.nklz, xoaqhysu_.hwxy, mptanxfe_.gyzu, mptanxfe_.tpwn, mptanxfe_.oefk, mptanxfe_.sdhm, mptanxfe_.jnks, rqtlogzs_.jiaw, rqtlogzs_.jxab, rqtlogzs_.tfna, rqtlogzs_.qryb, rqtlogzs_.wqip, rqtlogzs_.ezoh, fjlxvpsa_.jiaw, fjlxvpsa_.ynib, fjlxvpsa_.srhd, fjlxvpsa_.rtvp, fjlxvpsa_.scbf, fjlxvpsa_.atcu, fjlxvpsa_.royv, fjlxvpsa_.vsuf, fjlxvpsa_.eghm, fjlxvpsa_.ldse, fjlxvpsa_.gbrx, fjlxvpsa_.vicn, fjlxvpsa_.vumd, fjlxvpsa_.crsf, fjlxvpsa_.transport_type"
" Sort Method: quicksort Memory: 31kB"
" -> Nested Loop Left Join (cost=147.15..288.44 rows=23 width=11358) (actual time=2.970..3.015 rows=3 loops=1)"
" -> Nested Loop Left Join (cost=147.15..280.18 rows=23 width=11319) (actual time=2.961..2.996 rows=3 loops=1)"
" -> Hash Left Join (cost=147.15..273.17 rows=23 width=10751) (actual time=2.950..2.975 rows=3 loops=1)"
" Hash Cond: (dysahzgm_.ovzw = awslirdk_.ezoh)"
" -> Nested Loop Left Join (cost=99.48..225.14 rows=9 width=10709) (actual time=2.075..2.094 rows=1 loops=1)"
" Join Filter: (ytlvcqzg_.ovzw = fjlxvpsa_.srhd)"
" -> Hash Left Join (cost=99.48..221.55 rows=9 width=10612) (actual time=2.041..2.060 rows=1 loops=1)"
" Hash Cond: (dysahzgm_.ovzw = rqtlogzs_.ezoh)"
" -> Hash Left Join (cost=85.49..207.45 rows=9 width=10576) (actual time=1.768..1.787 rows=1 loops=1)"
" Hash Cond: (iwuvafgk_.yzex = xvlabuyq_.ovzw)"
" -> Nested Loop Left Join (cost=79.92..201.77 rows=9 width=10533) (actual time=1.642..1.660 rows=1 loops=1)"
" -> Nested Loop Left Join (cost=79.92..200.70 rows=1 width=10517) (actual time=1.638..1.656 rows=1 loops=1)"
" -> Nested Loop Left Join (cost=79.92..200.33 rows=1 width=10494) (actual time=1.633..1.651 rows=1 loops=1)"
" -> Nested Loop Left Join (cost=79.92..195.54 rows=1 width=9514) (actual time=1.628..1.646 rows=1 loops=1)"
" Join Filter: (dysahzgm_.xblq = hnilvzfm_.ovzw)"
" -> Nested Loop Left Join (cost=79.92..191.35 rows=1 width=9453) (actual time=1.605..1.613 rows=1 loops=1)"
" -> Nested Loop Left Join (cost=79.92..183.07 rows=1 width=8885) (actual time=1.600..1.608 rows=1 loops=1)"
" Join Filter: (mnyjdetu_.ovzw = fvzojhdy_.xmbt)"
" -> Nested Loop Left Join (cost=79.92..169.92 rows=1 width=8337) (actual time=1.597..1.604 rows=1 loops=1)"
" Join Filter: (dysahzgm_.ovzw = mnyjdetu_.mxoi)"
" -> Nested Loop Left Join (cost=79.92..158.12 rows=1 width=7379) (actual time=1.595..1.602 rows=1 loops=1)"
" Join Filter: (ytlvcqzg_.ovzw = dysahzgm_.xwre)"
" -> Nested Loop Left Join (cost=79.92..144.60 rows=1 width=7142) (actual time=1.542..1.547 rows=1 loops=1)"
" -> Nested Loop Left Join (cost=79.92..143.81 rows=1 width=6872) (actual time=1.534..1.539 rows=1 loops=1)"
" Join Filter: (fyevhapc_.enoi = tszvlieo_.ovzw)"
" -> Hash Right Join (cost=79.92..142.11 rows=1 width=6704) (actual time=1.523..1.524 rows=1 loops=1)"
" Hash Cond: (cupsgrax_.wspa = mwsbkjag_.ovzw)"
" -> Seq Scan on adm_con_per cupsgrax_ (cost=0.00..54.77 rows=1977 width=1185) (actual time=0.005..0.299 rows=1977 loops=1)"
" -> Hash (cost=79.90..79.90 rows=1 width=5519) (actual time=0.647..0.647 rows=1 loops=1)"
" Buckets: 1024 Batches: 1 Memory Usage: 2kB"
" -> Nested Loop Left Join (cost=42.57..79.90 rows=1 width=5519) (actual time=0.618..0.635 rows=1 loops=1)"
" -> Nested Loop Left Join (cost=42.57..79.22 rows=1 width=3718) (actual time=0.608..0.624 rows=1 loops=1)"
" -> Nested Loop Left Join (cost=42.57..70.94 rows=1 width=3029) (actual time=0.599..0.615 rows=1 loops=1)"
" -> Nested Loop (cost=42.57..70.43 rows=1 width=2759) (actual time=0.592..0.608 rows=1 loops=1)"
" Join Filter: (ytlvcqzg_.jtug = kxvjqyus_.ovzw)"
" -> Nested Loop Left Join (cost=42.57..67.88 rows=1 width=2031) (actual time=0.568..0.583 rows=1 loops=1)"
" -> Hash Right Join (cost=42.57..63.39 rows=1 width=1960) (actual time=0.557..0.571 rows=1 loops=1)"
" Hash Cond: (ubqknswj_.ytbs = butwxadf_.ovzw)"
" -> Seq Scan on cs_tr_oe ubqknswj_ (cost=0.00..18.13 rows=713 width=95) (actual time=0.005..0.103 rows=713 loops=1)"
" -> Hash (cost=42.56..42.56 rows=1 width=1865) (actual time=0.309..0.309 rows=1 loops=1)"
" Buckets: 1024 Batches: 1 Memory Usage: 1kB"
" -> Hash Right Join (cost=16.89..42.56 rows=1 width=1865) (actual time=0.301..0.306 rows=1 loops=1)"
" Hash Cond: (butwxadf_.alpc = wdcjrgzu_.ovzw)"
" -> Seq Scan on me_ta_ov butwxadf_ (cost=0.00..23.03 rows=703 width=873) (actual time=0.006..0.111 rows=703 loops=1)"
" -> Hash (cost=16.87..16.87 rows=1 width=992) (actual time=0.057..0.057 rows=1 loops=1)"
" Buckets: 1024 Batches: 1 Memory Usage: 1kB"
" -> Nested Loop (cost=0.00..16.87 rows=1 width=992) (actual time=0.048..0.050 rows=1 loops=1)"
" -> Nested Loop (cost=0.00..16.55 rows=1 width=968) (actual time=0.040..0.040 rows=1 loops=1)"
" -> Index Scan using cs_tr_oe_pkuy on cs_tr_oe ytlvcqzg_ (cost=0.00..8.27 rows=1 width=95) (actual time=0.027..0.027 rows=1 loops=1)"
" Index Cond: (id = 2718500)"
" -> Index Scan using me_ta_ov_pley on me_ta_ov fyevhapc_ (cost=0.00..8.27 rows=1 width=873) (actual time=0.007..0.007 rows=1 loops=1)"
" Index Cond: (id = ytlvcqzg_.ytbs)"
" -> Index Scan using ca_st_le on ce_st wdcjrgzu_ (cost=0.00..0.31 rows=1 width=24) (actual time=0.006..0.007 rows=1 loops=1)"
" Index Cond: (id = fyevhapc_.alpc)"
" -> Index Scan using pt_py on pt fibtujpk_ (cost=0.00..4.47 rows=1 width=71) (actual time=0.009..0.009 rows=1 loops=1)"
" Index Cond: (wdcjrgzu_.lihd = id)"
" -> Seq Scan on or_it kxvjqyus_ (cost=0.00..1.69 rows=69 width=728) (actual time=0.005..0.011 rows=69 loops=1)"
" -> Index Scan using or_no_fe on org_node lxubozfy_ (cost=0.00..0.50 rows=1 width=270) (actual time=0.004..0.004 rows=1 loops=1)"
" Index Cond: (kxvjqyus_.vgsr = id)"
" -> Index Scan using ad_ca_ke on ad_ca ajkqehut_ (cost=0.00..8.27 rows=1 width=689) (actual time=0.005..0.005 rows=1 loops=1)"
" Index Cond: (fyevhapc_.kspe = id)"
" -> Index Scan using pe_am_aa_ep on pe_am_aa mwsbkjag_ (cost=0.00..0.67 rows=1 width=1801) (actual time=0.006..0.006 rows=1 loops=1)"
" Index Cond: (ajkqehut_.wspa = id)"
" -> Seq Scan on or_se tszvlieo_ (cost=0.00..1.31 rows=31 width=168) (actual time=0.002..0.004 rows=31 loops=1)"
" -> Index Scan using or_no_pl on or_no bpcafleg_ (cost=0.00..0.78 rows=1 width=270) (actual time=0.004..0.004 rows=1 loops=1)"
" Index Cond: (tszvlieo_.vgsr = id)"
" -> Nested Loop Left Join (cost=0.00..13.51 rows=1 width=237) (actual time=0.049..0.050 rows=1 loops=1)"
" Join Filter: (dysahzgm_.jzxe = jcpizqwg_.ovzw)"
" -> Index Scan using em_so_cr_cd_fg_e_fl_ux on em_so_c dysahzgm_ (cost=0.00..8.27 rows=1 width=185) (actual time=0.007..0.008 rows=1 loops=1)"
" Index Cond: (cs_tr_oe_fk = 2718500)"
" -> Seq Scan on co_per jcpizqwg_ (cost=0.00..3.44 rows=144 width=52) (actual time=0.007..0.029 rows=144 loops=1)"
" -> Seq Scan on em_Care mnyjdetu_ (cost=0.00..10.80 rows=80 width=958) (actual time=0.000..0.000 rows=0 loops=1)"
" -> Seq Scan on ca_Eff fvzojhdy_ (cost=0.00..11.40 rows=140 width=548) (actual time=0.000..0.000 rows=0 loops=1)"
" -> Index Scan using em_pk on em gudancsq_ (cost=0.00..8.27 rows=1 width=568) (actual time=0.000..0.000 rows=0 loops=1)"
" Index Cond: (dysahzgm_.jage = id)"
" -> Seq Scan on em_ho_mot hnilvzfm_ (cost=0.00..2.97 rows=97 width=61) (actual time=0.005..0.015 rows=97 loops=1)"
" -> Index Scan using dr_sp_pl on dr_sp ytxhsgnr_ (cost=0.00..4.78 rows=1 width=980) (actual time=0.001..0.001 rows=0 loops=1)"
" Index Cond: (fvzojhdy_.eliu = id)"
" -> Index Scan using dr_qu_un_pl on dr_qu_uni qvfkanxz_ (cost=0.00..0.35 rows=1 width=23) (actual time=0.001..0.001 rows=0 loops=1)"
" Index Cond: (fvzojhdy_.lzbv_lmqpd = id)"
" -> Index Scan using em_ca_pl on eM_Car_fdef iwuvafgk_ (cost=0.00..0.96 rows=9 width=16) (actual time=0.000..0.000 rows=0 loops=1)"
" Index Cond: (mnyjdetu_.ovzw = efe_Cf_fgr)"
" -> Hash (cost=3.59..3.59 rows=159 width=43) (actual time=0.115..0.115 rows=159 loops=1)"
" Buckets: 1024 Batches: 1 Memory Usage: 13kB"
" -> Seq Scan on ca_it xvlabuyq_ (cost=0.00..3.59 rows=159 width=43) (actual time=0.007..0.046 rows=159 loops=1)"
" -> Hash (cost=8.44..8.44 rows=444 width=36) (actual time=0.263..0.263 rows=444 loops=1)"
" Buckets: 1024 Batches: 1 Memory Usage: 30kB"
" -> Seq Scan on em_ca_te rqtlogzs_ (cost=0.00..8.44 rows=444 width=36) (actual time=0.007..0.134 rows=444 loops=1)"
" -> Materialize (cost=0.00..3.46 rows=1 width=97) (actual time=0.030..0.030 rows=0 loops=1)"
" -> Seq Scan on tra fjlxvpsa_ (cost=0.00..3.45 rows=1 width=97) (actual time=0.025..0.025 rows=0 loops=1)"
" Filter: (cu_cs_tr_oe_fk = 2718500)"
" -> Hash (cost=29.52..29.52 rows=1452 width=42) (actual time=0.865..0.865 rows=1452 loops=1)"
" Buckets: 1024 Batches: 1 Memory Usage: 125kB"
" -> Seq Scan on em_em_attr awslirdk_ (cost=0.00..29.52 rows=1452 width=42) (actual time=0.005..0.356 rows=1452 loops=1)"
" -> Index Scan using em_pk on em xoaqhysu_ (cost=0.00..0.29 rows=1 width=568) (actual time=0.004..0.004 rows=1 loops=3)"
" Index Cond: (awslirdk_.grtk = id)"
" -> Index Scan using per_pk on per mptanxfe_ (cost=0.00..0.35 rows=1 width=39) (actual time=0.003..0.004 rows=1 loops=3)"
" Index Cond: (xoaqhysu_.tqid = id)"
"Total runtime: 6.108 ms"
Hors ligne
#7 23/10/2013 00:19:58
- gleu
- Administrateur
Re : Optimisation serveur
Un plan d'exécution, ça se colle dans explain.depesz.com... http://explain.depesz.com/s/JNB
Pour commencer, on est très loin des 1200 ms dont vous parlez. On a ici une exécution en 3 ms.
Ce qu'on voit directement avec cette URL, c'est que sur 3,3 ms d'exécution, PostgreSQL passe 3,2 ms à trier les données à cause du DISTINCT. Soit le DISTINCT ne sert à rien et il faut le virer. Soit il sert à quelque chose mais il n'est intéressant que sur certaines colonnes. Tout dépend de votre schéma de données, et là on ne va rien pouvoir dire.
Guillaume.
Hors ligne
#8 23/10/2013 09:39:08
- Blogger
- Membre
Re : Optimisation serveur
Bonjour,
Merci, je ne connaissais pas explain.depesz.com
Concernant les 1200ms, voici la preuve en image, ou alors j'ai rien compris au temps d’exécution, voici ce que me retourne PgAdmin3:
La requête sans EXPLAIN ANALYSE => http://img15.hostingpics.net/pics/372494req01.png
la requête en ajoutant EXPLAIN ANALYSE devant le SELECT => http://img15.hostingpics.net/pics/615691req02.png
La requête est-elle vraiment exécuter avec EXPLAIN ANALYSE?
Êtes-vous d'accord que le fait d'utiliser les DISTINCT est signe qu'il a y des erreurs/problèmes dans le schéma de données? Pour moi il ne doit pas avoir de doublon dans une base de données
Merci
Hors ligne
#9 23/10/2013 09:40:46
- kenrio
- Membre
Re : Optimisation serveur
vous etes sur le meme réseau ? ou la machine est dans un datacenter ?
Hors ligne
#10 23/10/2013 11:14:18
- Blogger
- Membre
Re : Optimisation serveur
Même réseau, quel rapport?
Hors ligne
#11 23/10/2013 12:31:41
- kenrio
- Membre
Re : Optimisation serveur
en bas a droite si mes souvenirs sont bon c'est le temps global incluant le temps réseau, alors que le temps de l'explain c'est le temps d'exécution sur le serveur.
Hors ligne
#12 23/10/2013 16:44:38
- Blogger
- Membre
Re : Optimisation serveur
Bonjour,
Je ne pense pas que ça sois le réseau, voici les résultat sans le DISTINCT:
- Sans DISTINCT => http://img11.hostingpics.net/pics/294657req03.png
- Sans DISTINCT et avec EXPLAIN ANALYSE => http://img11.hostingpics.net/pics/896122req04.png
Et j'ai beau le refaire 20 foiss de suite, j'arrive toujours dans ces temps la, si je remet le DISTINCT je retombe aux alentours de 1200ms...
Dernière modification par Blogger (23/10/2013 16:44:59)
Hors ligne
#13 23/10/2013 23:59:08
- gleu
- Administrateur
Re : Optimisation serveur
Ce n'est pas forcément le réseau, c'est aussi le temps de remplissage du tableau, et le temps d'affichage.
Pour le dire autrement, ce qui donne la durée d'exécution de la requête, c'est le EXPLAIN. D'ailleurs, ça se voit sur http://img15.hostingpics.net/pics/615691req02.png, vous avez "Total runtime: 5.903ms", soit 5,9 ms d'exécution de la requête sur le serveur. 1280ms est le temps d'exécution de la requête, de récupération de la donnée et d'affichage.
Guillaume.
Hors ligne
#14 24/10/2013 09:28:00
- Blogger
- Membre
Re : Optimisation serveur
Bonjour,
Alors expliquer moi pourquoi une telle différence:
- Quand j'ai le DISTINCT: Total runtime: 5.903ms, temps: 1280ms pour 3 lignes
- Quand j'ai pas DISTINCT: Total runtime: 6.490ms, temps: 50ms, pour 3 lignes aussi
Le temps d’exécution de la requête serait les mêmes, mais les temps sont différents pour l'afficher, alors qu'il affiche le même tableau?? j'ai de la peine à y croire.
Hors ligne
#15 24/10/2013 09:36:12
- kenrio
- Membre
Re : Optimisation serveur
de mon coté je comprend pas désolé...
Hors ligne
#16 24/10/2013 10:52:34
- Blogger
- Membre
Re : Optimisation serveur
de mon coté je comprend pas désolé...
Que-ce que vous ne comprenez pas? ce temps total runtime?
Je viens de faire un test, j'ai encore regardé dans les log, voici ce que j'ai:
- 2013-10-24 10:34:45 CEST LOG: duration: 1340.283 ms statement: SELECT DISTINCT
- 2013-10-24 10:35:04 CEST LOG: duration: 51.286 ms statement: SELECT
et les temps dans PgAdmin3:
- Avec DISTINCT: 1358ms
- Sans DISTINCT: 64ms
Donc on voit bien que la requête fait ~1200ms à l'execution
Au final que signifie ce total runtime?
Merci
Dernière modification par Blogger (24/10/2013 10:53:43)
Hors ligne
#17 24/10/2013 11:40:13
- kenrio
- Membre
Re : Optimisation serveur
oui je capte pas ce délire ^^
sinon y a moyen de lancer la commande en psql direct sur la machine a la place de pgadmin ?
Dernière modification par kenrio (24/10/2013 11:40:29)
Hors ligne
#18 24/10/2013 13:25:04
- Blogger
- Membre
Re : Optimisation serveur
Oui je peux faire direct sur le serveur, voici les commandes que j'ai fais:
- psql -f req_01_DISTINCT_EXPLAIN.sql -o res_DISTINCT_EXPLAIN.txt nom_base => Total runtime: 7.796 ms
- psql -f req_01_EXPLAIN.sql -o res_EXPLAIN.txt nom_base => Total runtime: 7.125 ms
Si je fais sans EXPLAIN ANALYSE, j'ai le résultat des lignes, mais sans le temps d’exécution, y-a-t-il une option dans psql pour avoir le temps d'exécution?
Merci
Hors ligne
#19 24/10/2013 14:32:46
- kenrio
- Membre
Re : Optimisation serveur
quand on est dans le psql on fait un \timing mais en extérieur je sais pas.
Hors ligne
#20 25/10/2013 09:51:05
- Blogger
- Membre
Re : Optimisation serveur
Bonjour,
J'ai essayé le \timing, Cela me rapporte le même temps que dans les fichiers log de Postgres.
J'ai essayé une petite requête qui fait un simple SELECT: SELECT * FROM table WHERE champ1='blabla' ORDER BY date_creation DESC
Dans psql j'arrive à 10ms de moyenne environ.
Si je fais un EXPLAIN ANALYSE, voici les résultats:
Temps: 2.773ms
Total runtime: 0.806ms
Du coup EXPLAIN ANALYSE exécute vraiment la requête?
Hors ligne
#21 25/10/2013 09:56:58
- Bidou
- Membre
Re : Optimisation serveur
Bonjour,
EXPLAIN ANALYZE lance effectivement la requête et ne se limite pas à en afficher le plan théorique.
Hors ligne
#22 25/10/2013 10:24:54
- rjuju
- Administrateur
Re : Optimisation serveur
C'est exact, il faut donc faire particulièrement attention s'il s'agit d'une requête UPDATE ou DELETE car les données seront modifiées. Il faut donc entourer l'EXPLAIN ANALYZE d'un begin/rollback.
L'EXPLAIN ANALYZE va chronométrer chacun des nœuds du plan d'exécution, et le temps total d'exécution sera donc en général un peu plus important que le temps de la requête si elle était exécutée normalement, du fait du chronométrage.
Julien.
https://rjuju.github.io/
Hors ligne
Pages : 1