Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#26 13/05/2014 16:06:07
- saigamp
- Membre
Re : mauvais choix de l'optimiseur
Je relance encore ce topic...
Après avoir mis en doute le matériel, je remets en doute la partie logiciels. Afin de bien comparer, j'ai installé une base de données Oracle 11g sur le même type de machine que celle sur laquelle j'ai fait mes tests avec PostgreSQL: machine virtuelle hébergée sur le même datastore, exécutée par le même ESX, avec le même OS Debian et la même quantité de ressources. Je fais les tests sur les mêmes tables (export avec oracle_fdw). La requête passe par défaut par un HashAggregate et met 23s. En forçant le group by à passer par un GroupAggregate à l'aide d'un hint la requête met 41s (contre 10min avec PostgreSQL). Étant donné que le GroupAggregate fait aussi son tri sur disque (le tablespace temporaire est utilisé pour la requête), on peut dire que le matériel peut supporter la charge d'un GroupAggregate ce qui n'est pas le cas avec PostgreSQL. Ceci me fait dire que je dois avoir un problème de configuration quelque part. Les tests sont faits avec une installation à partir du paquet postgresql-9.3 et avec des clusters créés à partir de pg_createcluster ou initdb.
Les résultats de vmstat ci-dessous (intervalle de 5s) montre que Oracle écrit fortement pendant une trentaine de secondes en même temps qu'il utilise la CPU. Sous PostgreSQL, il n'écrit fortement que toutes les 35s environ et consomme de la CPU pendant toute la durée de la requête. Que fait-il entre 2 séances d'écritures? A priori c'est pendant les périodes de non écriture qu'il perd du temps. De plus, après la dernière "écriture", il passe près de 4 min à travailler sur CPU. Sur la machine physique, le phénomène est le même; ça ne doit donc pas être lié à la virtualisation. Comprenez-vous ce type de comportement? Faut-il des infos supplémentaires sur ma configuration?
vmstat Oracle
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 0 997376 14984 2897928 0 0 1262 3023 1072 2093 17 12 69 2
1 0 0 931888 15000 2897920 0 0 0 30 1095 1990 34 4 62 0
1 0 0 847328 15016 2898272 0 0 0 19289 1289 2068 82 12 0 6
0 1 0 847328 15024 2898272 0 0 0 21202 1319 2118 85 9 0 6
1 0 0 847328 15048 2898272 0 0 0 21706 1303 2091 86 8 0 6
1 0 0 847204 15056 2898272 0 0 0 19804 1301 2081 85 9 0 6
1 0 0 847204 15080 2898272 0 0 0 19626 1309 2102 87 8 0 5
1 0 0 847204 15088 2898272 0 0 0 22246 1309 2108 86 7 0 6
1 0 0 996624 15104 2898280 0 0 0 18555 1284 2075 84 10 1 6
0 0 0 996500 15120 2898272 0 0 0 29 1012 1984 0 0 99 0
0 0 0 996500 15128 2898284 0 0 0 25 1007 1989 0 0 100 0
0 0 0 996500 15144 2898284 0 0 0 18 1011 1986 0 0 99 0vmstat PostgreSQL
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 104 3588416 62172 315624 0 0 30 42 37 44 1 0 99 0
2 0 104 3565460 62180 315812 0 0 0 10 91 42 23 1 76 0
1 0 104 3559500 62196 321360 0 0 0 28 277 41 100 0 0 0
1 0 104 3554424 62204 326580 0 0 0 7 282 33 99 1 0 0
1 0 104 3549340 62220 331628 0 0 0 18 279 38 100 0 0 0
1 0 104 3544000 62228 336620 0 0 0 10 283 38 100 0 0 0
1 0 104 3539296 62244 341664 0 0 0 10 277 35 100 0 0 0
1 0 104 3534088 62252 346692 0 0 0 11 281 37 100 0 0 0
1 0 104 3528624 62268 351676 0 0 0 6442 289 39 100 0 0 0
1 0 104 3523920 62276 356668 0 0 0 15 277 36 100 0 0 0
1 0 104 3518836 62292 361780 0 0 0 6 279 36 99 1 0 0
1 0 104 3513620 62304 366892 0 0 0 16 279 40 100 0 0 0
1 0 104 3508916 62320 371952 0 0 0 10 279 34 100 0 0 0
1 0 104 3503708 62328 376900 0 0 0 8 274 36 100 0 0 0
1 0 104 3498492 62348 382076 0 0 0 22 276 40 100 0 0 0
1 0 104 3493292 62356 387200 0 0 0 7098 297 35 99 1 0 0
1 0 104 3488208 62372 392272 0 0 0 11 279 37 99 0 0 0
1 0 104 3482868 62380 397456 0 0 0 10 281 39 100 0 0 0
1 0 104 3478164 62396 402524 0 0 0 10 278 34 99 1 0 0
1 0 104 3473080 62404 407532 0 0 0 9 284 36 100 0 0 0
1 0 104 3467864 62420 412572 0 0 0 14 282 39 100 0 0 0
2 0 104 3462540 62428 417800 0 0 0 6118 290 36 99 1 0 0
1 0 104 3457580 62444 422804 0 0 0 14 279 35 100 0 0 0
1 0 104 3452488 62452 427828 0 0 0 10 283 39 100 0 0 0
1 0 104 3447784 62468 432880 0 0 0 16 280 36 100 0 0 0
1 0 104 3442452 62476 438016 0 0 0 2 281 37 99 1 0 0
1 0 104 3437360 62492 443060 0 0 0 20 280 39 100 0 0 0
1 0 104 3432532 62500 448112 0 0 0 7 280 35 100 0 0 0
1 0 104 3427076 62520 453256 0 0 1 7118 296 39 99 0 0 0
1 0 104 3421736 62528 458388 0 0 0 10 281 39 99 1 0 0
1 0 104 3417032 62544 463420 0 0 0 11 284 35 99 1 0 0
1 0 104 3411948 62552 468524 0 0 0 14 284 36 100 0 0 0
1 0 104 3406608 62568 473620 0 0 0 14 282 39 100 0 0 0
...Hors ligne
#27 13/05/2014 21:50:39
- gleu
- Administrateur
Re : mauvais choix de l'optimiseur
Les implémentations Oracle et PostgreSQL sont tellement différentes que les comparer (en dehors de comparer la durée pure et simple d'une requête) n'apporte pas grand chose.
Quand à la compréhension du comportement de PostgreSQL, non, pas vraiment de détails à vous donner. Il faudrait avoir la main sur la machine pour pouvoir faire plus de tests. C'est assez difficile à faire à distance.
Guillaume.
Hors ligne