bonjour,
Lors de ma formation il y a bien longtemps on m'avait dit. Que 1 vcpu par Virtuel machine (VM) etait bien car vmware se chargeait de repartir la charge sur les autres cpu physique ou socket si besoin.
J'ai des ESXI avec 2 CPU et 6 socket. Ils ne sont pas trés utilisés (entre 5 et 20% d'utilisations).
J'ai un application qui est assez lente. Par exemple quand un biologiste doit valider un examen il peut attendre jusqu'a 30 seconde l'affichage de sa page...
C'est une appli sous red hat et Oracle.
Y a t'il des cas ou il faut augmenter le nombre de processeur pour une VM ? ou alors c'est une mauvaise piste ?
merci

Hello,  
Ca me semble assez foufou ! Il ne faut pas trop sur-allouer les vCPU par rapport au nombre de CPU physiques de ton hôte, mais avec 1 seul vCPU je pense que tu bride énormément ta VM... Côté VM, ton OS ne verra qu'un seul coeur (cat /proc/cpuinfo) et tes applis potentiellement multithreadées tourneront "à l'ancienne" quasiment en séquentiel.  
 
Il faut surveiller les stats de tes VM pour voir où se trouvent les contentions, mais tu peux jeter un oeil aux bestpractices pour rééquilibrer un peu les ressources : http://www.vmware.com/pdf/Perf_Bes [...] ere5.0.pdf

http://www.vmware.com/files/pdf/pa [...] _Guide.pdf
page 12

donc vcpu ne change rien

 
Ta conclusion est trop rapide.
 
Il est recommandé de baisser le nbre de vCPU si leur augmentation n'est pas bénéfique.
Mais leur augmentation peut être bénéfique !
 
Tout dépend la charge CPU de ta VM.
 
1 vCPU, c'est l'équivalent en puissance d'un core physique; pour peu que cette puissance soit disponible sur l'ensemble des cores physiques (hors paramétrages d'affinité et de réservation).
Une VM peut nécessiter plus de puissance et il est alors utile d'augmenter le nbre de vCPU.

ok donc sur mon esxi avec 2 xeon E5630 (6 coeur, 12M Cache, 2.53 GHz)
Si je donne qu'un vcpu sur ma VM, il utilise qu'un cpu de 2.53ghz sur mon serveur physique ?

Il met à disposition l'équivalent temps CPU d'un core physique.
Après c'est l'hyperviseur qui, en dehors de paramétrages spécifiques, va gérer cette charge au niveau physique (sur un seul core ou répartie sur plusieurs cores).
 
C'est facile à vérifier : tu charges ton vCPU sur le VM et tu regardes dans le client vSphere la charge CPU de l'hôte.

Un seul vCPU par VM est de toute façon trop limitant, si ton CPU est bloqué par des IO, l'ensemble de la machine se bloque quasiment, alors que les programme récent profite pas mal de 2 à 4 cores en général.
 
Enfin la répartition de vCPU dépend fortement du type d'application et de la charge visée quand même.

Renseigne-toi auprès de l'éditeur des prérequis de l'application.

lors de la mise en place, il n'y en avait pas.
je l'ai contacté, maitenant ils en mettent 2vcpu 2core

Sur les grosses infra avec beaucoup de vm, il est conseillé de limite le nbre de vcpu afin de limiter l'impact sur le nombre de transition à gérer (plus de Vcpu == Plus de transition à gérer). Après si ton application est multithreadé, et que tu as pas trop de charge sur l'ensemble de ton/tes esx, augmenter le nombre de vcpu est la piste à suivre

 
Faux (en partie) !
 
Le principe de base de l'état d'un process est le suivant :
Un ordonnanceur établit quel process est élu. Pour être élu, le process doit être en statut prêt. Si il n'est pas dans ce statut, alors il passe au process suivant.
 
Il existe ainsi trois statuts de process (simplifié) :
- Elu : c'est le process qui tourne actuellement. Il ne peut y en avoir qu'un par (v)Core (on oublie ici l'Hyper-threading, etc).
- Prêt : c'est un process qui est actuellement en attente d'être élu. Son job est terminé, et il n'a plus besoin que du CPU pour continuer sa routine.
- Bloqué : ce process ne peut pas être élu. Il est bloqué car il est en attente d'une ressource externe (lecture disque dur, USB, etc). Le DMA est alors chargé de rapatrier les infos nécessaire du périphérique vers la mémoire où réside le process. Quand le DMA a terminé son job, il positionne un flag pour le process pour qu'au prochain tick horloge, l'ordonnanceur place le process de bloqué à prêt.
 
Donc grosso-modo, et c'est une discussion que j'ai déjà eu ici en interne, quand une VM est vachement lente, et que le total CPU usage du host est vraiment bas, il faut voir le soucis ailleurs. Il se peut que le nombre de vCore assigné est trop bas (1vCore par exemple), mais souvent ce sont les temps d'accès au VHD qui rend la VM très lente (si on ne prend pas en compte l'état de la mémoire, le swaping etc).  

merci pour ces information.s
pour mon cas, c’était un problème de nombre de vcpu insuffisant .
avant ma VM avait au max 2.4Ghz, maintenant c'est 9.6 Ghz a sa disposition.

Je comprend que pour monsieur et madame tout le monde, c'est plus facile de comprendre que 1 coeur = 2.4Ghz, 2 coeurs = 4.8Ghz etc, mais n'oubliez pas que ce n'est pas du tout le cas
 
Une application monothreadée ne pourra profiter que d'un coeur cadencé à 2.4Ghz. Alors qu'un coeur à 4.8Ghz rendrait l'application potentiellement deux fois plus rapide (en terme d'exécution de routines).
 
En contrepartie, offrir plus de coeurs offre toujours la possibilité d'utiliser du multithreading, et ça c'est bien !