Version imprimable
Bonjour ,
En 11g , j'ai parallélisé 3 requêtes SELECT complexes R1 R2 R3 ce matin avec un degré 10.
Temps avant // :
R1 : 1H
R2 : 1H20
R3 : 40min
Temps après // (une après l'autre) :
R1 : 12min
R2 : 16min
R3 : 5min
Temps après // (les 3 simultanément) :
R1 : 1H10min !!!
R2 : 1H30min !!!
R3 : 50min !!!
Constat : Dégradation des perfs si les 3 SELECT s'exécutent en même temps et en //.
Qu'elle solution pour éviter cette dégradation ?
merciiii
Bonjour,
Ben faites les select parallélisés à la suite, pas en même temps.
Vu le grand nombre de questions que vous vous posez sur Oracle et la performance, je vous conseille de faire un peu de lecture, vous gagnerez un temps immense en plus d'avoir l'impression de savoir ce que vous faites. ;)
http://docs.oracle.com/cd/E11882_01/...e10822/toc.htm
Et dans un second temps:
http://docs.oracle.com/cd/E11882_01/...e16638/toc.htm
Il y a également de très nombreuses ressources en français sur developpez.net grâce au travail de quelques membres.
ne jamais trop paralléliser. En effet à un moment donné il faut passer du mono au multithread et inversement. Au moment du rassemblement des threads ceci induit des temps d'attente car aucun des thread en // ne finit en même temps. Conclusion : trop de parallélisme tue le parallélisme.
Refaites des essais avec 2, 4 et 8 core.
Enfin tout dépend aussi de votre architecture hardware. Avec une machine à 4 noeuds NUMA de 4 coeurs, il ne faut pas dépasser 4 en // car sinon vous risquez des temps d'attente d'intercommunication entre CPU.
Si en plus vous êtes virtualisé.... catastrophe !
Pour plus d'informations, lisez la chapitre Administration de mon livre sur SQL.
A +
Je voulais tester un cas concret où 3 utilisateurs lancent 3 SELECT parallélisées en même temps.Citation:
Envoyé par Rams7s
Pour info j'ai une machine avec 4 CPU.
Ne pas paralléliser ! Ou paralléliser à un degré inférieur à votre nombre de CPU x nombre d'utilisateurs simultanés.Citation:
Envoyé par tropiko
Voyez vos requêtes comme des convois de camions, et les CPUs comme des péages. Vous avez 4 péages, et un seul train de camions : ça risque fort d'aller plus vite s'il passe par les 4 péages que par un seul. Il y a de la déperdition en amont et en aval pour diviser / remettre le convoi en bon ordre, mais le temps de passage est divisé par 4. Au final avec un bon manager et un convoi facilement divisible, on peut gagner beaucoup de temps.
Maintenant, vous avez 3 convois en même temps : là ça devient franchement le bordel ! Non seulement la contention est quasiment identique en séparant chaque convoi sur les 4 péages qu'en les assignant chacun à 1 péage, mais du coup les temps en amont et en aval deviennent juste de la charge en plus - et il faut que les managers de chaque convoi s'entendent, etc. Bref, globalement on va plus perdre du temps qu'autre chose à vouloir paralléliser.
Bonjour,
Le but de paralléliser, c'est d'utiliser au maximum les ressources d'une machine. Mais si on parallélise trop, au contraire on amène de la contention.
Ici lorsque les 3 requêtes tournent en même temps, vous avez: 10 * 3 = 30 process qui travaillent en parallèle. Imaginons que ces requêtes travaillent 60% de leurs temps en CPU et 40% de leur temps en i/o, alors en moyenne, il y aura une charge de 18 en CPU. Donc c'est ok si vous avez 20 cores, par contre il y aura contention (attente en runqueue) si vous n'en avez que 4.
Même raisonnement sur les i/o: y a-t-il assez de disque pour tenir ces demandes d'i/o
Le calcul est très hypothétique (c'est sur des moyennes, mais l'activité peut être très variable). Pour déterminer le degré de parallélisme optimal, il faut surveiller la charge du système.
Mais il peut aussi y avoir d'autres raisons.
Suivant la configuration du parallélisme, Oracle peut se retrouver à changer le degré demandé, voire lancer la requête en serial. Ces mécanismes peuvent permettre d'adapter le degré en fonction de la charge.
Cordialement,
Franck.