Bonjour,
 
J'ai un serveur Virtuel sous win2008 R2 qui a son CPU souvent bloqué à 100%.
 
C'est un serveur TSE et quand je regarde dans le moniteur des ressources j'observe 2 processus qui ont un UC moyenne à environs 20.
 
Il s'agit de :  spoolsv.exe et AcoRD32.
 
Pouvez vous m'aider, merci.

Spoolsv.exe c'est le spooler d'impression, service windows.
Peut être un problème de pilote (voir eventvwr)
l'autre c'est Acrobat reader. Un pdf de 30pages peut bouffer 20% cpu

essaye de voir si c'est une imprimante en particulier et change le driver.
Le modèle n'est peut être pas compatible avec 2008 r2.

Je vais surveiller....

Regarde bien que les processus de tous les utilisateurs sont affichés dans ton gestionnaire des tâches.
Utilise un logiciel type ProcessExplorer pour avoir plus de détails eventuellement.
 
Dans tous les cas, c'est pas très bon signe

Bonjour,
 
As-tu une solution antivirus?

Oui SOPHOS..

salut,  
 
si la surveillance des process utilisateurs n'apporte rien, autre piste à voir, le dimensionnement de ta VM (1 ou 2 vCPU ?), et tester une réservation de ressources CPU dans l'hyperviseur (par exemple chez nous on a un gros TSE bien chargé avec pas mal d'utilisateurs et on a du lui réserver en plus 4000Mhz de cpu et monter les shares sur high pour avoir des perfs correctes sans que les gens gueulent au moindre clic... c'est moche, mais vu ce qu'ils font dessus on a pas trouvé mieux).
Les joies des applis et des navigateurs bien lourds sur un TSE...
 
Essaie d'identifier avec tes utilisateurs ce qu'ils ouvrent en PDF aussi, un fichier avec 12000 couches généré avec une appli moisie peut allègrement te consommer un gros paquet de ressources... (tester en le retraitant dans un acrobat pro ou solution équivalente pour optimiser le fichier).
 
 
 

 
Notre TSE a 4 Vcpu et 25 de RAM pour 30 utilisateurs.
 
Je test la reservation et les shares sur hight

 
Bonjour,
 
Ton commentaire est très intéressant car après l'avoir lu, la première chose qui m'est venu à l'esprit est : "Voila, ça arrive parfois que les limites de la virtualisation sont atteints. Alors on applique un sparadrap ici et là, on augmente le nombre de vCPU, on augmente les prios, etc."
En soit, c'est tout à fait "logique" et "légitime", mais est-ce vraiment une bonne idée ? Ne faudrait-il pas être plus "raisonnable" et éviter de vouloir toujours tout virtualiser ?
 
Je réagis ainsi car encore hier en fin de journée j'apprenais que mon boss voulais virtualiser les SQL Servers, SSIS, etc... Ce qui est une trèèèès mauvaise idée en terme de performance.
 
Je ne souhaite pas lever un débat (qui a déjà fait couler beaucoup d'encre ici et là), mais s'obstiner à tout virtualiser, ce n'est pas une bonne idée à mon sens.    
 
Bonne journée à vous tous

virtualiser ça permet de ne plus être dépendant du matériel, c'est quand même trés souple.
Sauf quand ton serveur physique est sous dimensionner.
C'est plus un probléme d'ajout de serveur physique (donc d'investissement) que de probléme de virtualisation.

Le problème ne vient pas de la virtualisation hein ... (enfin si on parle ici d'un VMware/Hyper-V récent, ou l'overhead sera <5%)

Forcément, si on fait tourner 2/10/50/100 VM sur un serveur il ne faut  pas s'étonner que chacune n'ai pas les perfs du serveur physique en lui même.

Virtualiser du SQL Server ça se fait très bien pour peu que tout soit dimensionné correctement et que la couche de virtualisation soit moderne.

Virtualiser un TSE/RDS c'est effectivement pas une bonne idée si tu as beaucoup d'utilisateurs dessus.
 
25 Go de RAM pour 30 users c'est trop juste, même si c'est pas en relation avec ton problème.

 
Que me conseilles tu comme dimensioning ?

Que font tes utilisateurs au quotidien dessus ?

Ajouter de la ram ne réglera pas des problèmes de saturation CPU. (ça peut contribuer si le serveur en manque, mais ça n'est pas la source du problème.)
 
Il faudrait nous donner :
- Modèle et nombre de processeurs physiques sur l'hôte. (sockets)
- Type et version de l'hyperviseur
- Nombre de vCPU attribués à la VM.
- Nombre de VM qui se partagent l'hôte physique et description des workloads.
- Éventuellement les stats d'utilisation du serveur physique ("\Hyper-V Hypervisor Logical Processor(_Total)\% Total Run Time" par exemple pour de l'hyper-v)

C'est pas un problème de dimensionnement non plus, vraisemblablement une impression PDF qui pourrit le CPU, donc plus un problème de cong/drivers/mauvaise utilisation de l'outil

Je pense aussi, mais j'essaye de creuser un peu plutôt que de laisser les gens dire "la virtualisation c'est pas perf"

Ca ne répond pas à tous les besoins simplement.

monter le nombre de vCPU a plus souvent l'effet inverse coté perfs car cela génère du cpu ready, qui au final écroule encore plus la réactivité.
 
pour citrix par exemple les préco que nous avons recues des intégrateurs sont 2vCPU (pas plus), et réservation de la mémoire (3,5Go pour les 32bit 8Go pour les x64 (pour la quantité de ram ca dépend du nombre d'utilisateurs et de ce qui va etre publié.(idem pour les TSE)).
Cela a pour impact de réduire fortement le nombre de VMs hébergées par l'ESXi.
 
Windows 2008 et supérieur ainsi que RH6 supportent le hotplug de cpu et de ram, ce qui permet d'en ajouter a chaud si besoin et donc d'ajuster les ressources au mieux.
 
certes, en virtu on aura pas les perfs d'une installation bare metal d'un os serveur, mais on gagne en fiabilité coté backups et haute disponibilité, dimensionnement des machines, etc.
la plupart des serveurs physiques sont surdimensionnés par rapport à leur utilisation réelle.
On a par exemple un esxi qui est dédié a une VM (128Go ram, 32 coeurs), et la machine est au taquet... mais on peut la migrer sur un autre esxi si l'hote est malade, on peut la restaurer en moins d'une heure avec veeam.
 
augmenter les shares ou effectuer des réservations fait partie du jeu, certains serveurs ou certaines applis ne supportent pas les allocations dynamiques de ram/ballooning, et il faut leur réserver les ressources pour leur bon fonctionnement.
 
et oui, +1 pour l'analyse des process qui génèrent ou intéragissent avec le pdf créé, et des drivers imprimante.
 

Il faut penser à associer des cpu qui ont des registres en commun. Sur un 4 coeurs hyperthreadé associer le vcpu 0 et 7 sera moins performant que le 0 et 1 (source certifié vmware).
 
Pour la virtualisation de sql server, les préco de MS sont de virtualiser l'instance si besoin est, mais pas le stockage. La performance du serveur est en grande partie basé sur l'accès disque, et virtualiser cet aspect revient à faire un raid/mettre vmfs/créer un disque virtuel/créer une partition ntfs/placer les bases de données.
 
Il y a beaucoup trop de couches et la perte de performance peut être dramatique, et c'est pire si une étape est mal faite. Je pense notamment à la phase création du vdisk et création des partitions. Si ceci est fait sans précaution on trouve un problème d'alignement de partition qui double le nombre d'I/O sur  disque.

Je plussoie la remarque de Gorn Nova :
..... on peut la migrer sur un autre esxi si l'hote est malade, on peut la restaurer en moins d'une heure avec veeam ....
 
Nous avons des serveurs physiques qui n'ont qu'une seule VM et ça peut sauver le jour où les blocs alim crament en même temps, le HBA fibre channel ou réseau claquent, ou la RAM ect .....
 
On gobe la vm sur un autre host ESX (à condition que le datastorage soit commun) et hop 3 minutes après la VM est opérationnelle, peut-être avec des perf dégradées mais au moins le client (ou le service de l'entreprise) peut fonctionner.
 
Les utilisateurs peuvent comprendre qu'un serveur soit lent temporairement pendant une panne ; ils sont beaucoup moins compréhensifs quand ils n'ont plus du tout d'accès à leur serveur (ou le service qui tourne dessus)