Vous n'êtes pas identifié(e).

#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  0

vmstat 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

Pied de page des forums