My Memory Dump

Aller au contenu | Aller au menu | Aller à la recherche

dimanche 23 novembre 2014

Performance Oracle, Optimiseur et CPU

Dans mon billet sur le paramètre "session_cached_cursor" (voir plus bas) je parlais de problèmes de temps de réponse Oracle liés au temps mis par l'optimiseur pour calculer le plan d'exécution des requêtes. Phénomène aggravé par le fait que l'application concernée utilisait des littéraux au lieu de variable "bind" donnant encore plus de travail à l'optimiseur.

Mon serveur Oracle est virtualisé et l'ajout de vCPU ne m'avait pas permis d'améliorer les choses. De toute façon les lenteurs de l'optimiseur étaient ressenties même avec un seul utilisateur connecté. Je ne suis pas sûr, mais je pense que l'optimiseur travail par "thread", un thread par session par exemple et je pense qu'un thread ne peut exploiter qu'un cœur de processeur. Donc l'ajout de vCPU ne change rien.

Suite à mon billet sur la compilation Visual Studio 2010 et l'intérêt de disposer de processeur avec "mode turbo" (voir plus bas) j'ai déplacé mon serveur Oracle sur un Hyper-v disposant de tels processeurs.

Bilan : Nette amélioration des temps de réponse Oracle et pourtant je ne suis passé que de 2.4 GHz à 2,8 GHz en mode turbo. J'attends avec impatience l'achat du prochain serveur Hyper-v pour lequel la fréquence CPU et le mode turbo seront privilégiés.

dimanche 19 octobre 2014

Visual Studio 2010, virtualisation Hyper-v et temps de compilation.

Je ne suis pas développeur (non, non). Je m'occupe de virtualisation.

Il y a peu on m'a demandé d'expliquer pourquoi une machine virtuelle Windows 7 avec Visual studio 2010 mettait presque trois fois plus de temps pour compiler un projet (vb.net) qu'une machine physique dans les mêmes conditions (même OS, mêmes applications et même projet à compiler). Les deux machines disposaient de 4 Coeurs et 8 Go de RAM. Sur l'hyperviseur, les machines virtuelles avaient toutes les mêmes paramètres en terme de priorité d'allocation de ressources. La charge moyenne des CPU de l'hyperviseur était de 15% (à l'aise quoi).

J'ai fait différents tests chronométrés, je vous passe les détails.

Première constatation : L'antivirus (OfficeScan de Trend Micro) augmente le temps de compilation d'environ 20%. Cela n'explique rien mais c'est un phénomène aggravant (plus c'est lent et plus c'est lent).
-> Création d'une exception afin que le scan en temps réel ne traite pas le dossier dans lequel les fichiers compilés sont générés.

Deuxième constatation : Après avoir changé la machine virtuelle d'hyperviseur (pour des questions de place), les temps de compilation ce sont nettement améliorés. J'ai pensé que la charge globale de l'hyperviseur était en cause, j'ai donc refait ma comparaison en arrêtant toutes les autres machines virtuelles. Même résultat.
- d'un coté un hyperviseur avec deux processeurs Xéon E5-2609 (2.4 Ghz acheté en 2012)
- de l'autre un hyperviseur avec deux processeurs Xéon E5630 (2.53 Ghz acheté en 2010)
Celui de 2010 donnant les meilleurs résultats.

En vérifiant les spec, je me suis aperçu que le Xéon E5-2609 n'avait pas de mode turbo, la fréquence indiquée est donc sa fréquence max contrairement au E5630 qui peut monter à 2.8 Ghz temporairement.

En revenant au comparatif initial, avec la machine physique, celle ci était équipée d'un processeur Core i5 3.3 Ghz avec un mode turbo à 3.7 Ghz. Donc d'un coté nous avions une VM avec 4 coeurs à 2.4 Ghz max et de l'autre une station de travail avec 4 coeurs à 3.7 Ghz max. Tout s'explique. A noter que le fait de passer à 8 coeurs sur la VM n'a rien changé, c'est donc bien de la puissance pure que l'on a besoin pour la compilation.

Conclusion : Plus la fréquence est haute et plus ça va vite (on s'en serait douté mais pas forcément à ce point) et surtout vérifier la fréquence max du mode turbo avant d'acheter votre prochain serveur Hyper-v (même si la charge moyenne de l’existant est faible).