VMware ESXi

[dsebire]

+1 poulpi

je viens de passer le mode HT a interne, je vais voir cette nuit comment ça se passe
pas envie de jouer avec affinité (pour l'instant)

[dsebire]

bon, a l'instant T, la seule constatation est une augmentation de l'utilisation CPU, aussi bien dans le VM que sur l'hôte :/
je laisse passer la nuit et la grosse charge pour voir, mais j'y crois pas trop

[dsebire]

bon bah cpu de l'hote toujours a 100% !
hier soir, je sais pas pk j'avais une surconso de CPU par rapport a d'habitude. peut être du au reboot et pas laissé assez de temps pour que ça se stabilise.

par contre, j'ai l'impression que ça pédale plus vite !
la VM fait le même job toutes les nuits, ça a été (un peu) plus court que d'habitude

pour la nuit prochaine, je vais jouer avec l'affinité CPU

[dsebire]

hello !

suite et fin:
avec l'affinité cpu sur 0-3 (donc les 2 premiers core avec leur HT)
cpu de la VM toujours a 100% (normal)
durée d'exécution 1h30 au lieu de 1h20 (+12%, normal)
le reglage pour l'HT est resté sur interne et non quelconque (par défaut)

cpu de l'hôte ne dépasse pas 50%

donc voila, si vous voulez forcer l'utilisation de l'HT, il faut nécessairement forcer l'affinité des CPU et passer le mode HT a interne, sinon il utilise par défaut les core physiques et non logiques.

dommage de devoir forcer l'affinité, surtout sur des machines ou il y a plein de VM (pas le cas ici mais j'en ai d'autres).
c'est le meilleur moyen pour avoir de la congestion sur quelques core pendant que les autres ne branlent rien.

Mr VMware, a quand une option pour forcer l'utilisation de l'HT SANS mettre l'affinité CPU ????

merci a tous pour les pistes de recherche qui ont mené a la solution

[poulpito]

il doit y avoir une autre solution
je suis pas un spécialiste vmware, je bricole avec mais je demanderai au boulot semaine pro car c'est intéressant quand même

la l'affinité 0-3 c'est brutal mais au moins ca permet de vérifier de toute facon dans n'importe quel monde de virtualisation vcpu = pas ce qui est consommé. y'a toujours une magouille derrière pour le vrai dimensionnement des ressources :/

[kalistyan]

J'ai eu une conversation du même style y a quelque temps... C'était déjà le flou artistique. :/

[dsebire]

je demanderai au boulot semaine pro car c'est intéressant quand même

up !!!

[poulpito]

ah oui tu fais bien de le dire ^^
je demande au collègue quand il arrive (il a du faire une inter a 4h du mat jpense qu'il est encore vaseux la )

[Ryu_wm]

Je sens que je vais avoir une question à poser ici d'ici peu
je viens de me rendre compte qu'une VM Win32 sous ESXi 6.5.1 à qui j'alloue le max de Vcore possibles, ne consomme en fait que 25% des ressources de l'hote esxi quand la VM est à 100%

[dsebire]

je demanderai au boulot semaine pro car c'est intéressant quand même

up !!! :'(

[kalistyan]

VMware ESXi
Version 6
Build 5050593

Google Chrome est à jour
Version 63.0.3239.84 (Build officiel) (64 bits)

Impossible d'utiliser l'interface web à partir de Chrome.

Code : Tout sélectionner

Cause : Error: [$rootScope:inprog] http://errors.angularjs.org/1.3.2/$rootScope/inprog?p0=%24digest
Version : 1.14.0
Build : 4940836
ESXi : 6.0.0
Navigateur : Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

Pile d'exception :

Error: [$rootScope:inprog] http://errors.angularjs.org/1.3.2/$rootScope/inprog?p0=%24digest
    at https://192.168.100.97/ui/scripts/main.js:316:20611
    at l (https://192.168.100.97/ui/scripts/main.js:318:12567)
    at k.$apply (https://192.168.100.97/ui/scripts/main.js:318:16690)
    at HTMLInputElement. (https://192.168.100.97/ui/scripts/main.js:320:828)
    at HTMLInputElement.dispatch (https://192.168.100.97/ui/scripts/main.js:315:14464)
    at HTMLInputElement.r.handle (https://192.168.100.97/ui/scripts/main.js:315:11251)
    at prop (https://192.168.100.97/ui/scripts/main.js:316:3018)
    at n.access (https://192.168.100.97/ui/scripts/main.js:315:6702)
    at n.fn.init.prop (https://192.168.100.97/ui/scripts/main.js:316:2642)
    at V.$set (https://192.168.100.97/ui/scripts/main.js:317:21408)

[dsebire]

reboot ?

essaie d'appliquer le dernier patch aussi si t'es pas a jour

[vhnet]

fait "echap" normalement ca passe

[kalistyan]

Effectivement "ECHAP" contourne le problème ! :d

Merci

[kalistyan]

https://www.vsan-essentials.com/

[kalistyan]

reboot ?
essaie d'appliquer le dernier patch aussi si t'es pas a jour

Dernier patch appliqué et reboot, le problème persiste.

6.0.0 Update 3 (Build 6921384)

[kalistyan]

Call "IscsiManager.QueryBoundVnics" for object "iscsiManager... failed.
=> https://communities.vmware.com/message/2557327#2557327

Cela peut service.

Testé & approuvé.

[jm@rc]

Actuellement en v5.5 u3b, passage en version 6.5 u1d prévue dans quelques mois avec licences Enterprise Plus et cluster HPE Simplivity. -> 112 cores (448 vcpu) / 1256 Gb RAM / 24 Tb SSD pour les VM et deux baies 3PAR 55 Tb SAS 15k pour les données utilisateurs en stretched cluster relié par des fibres noires 4*10 Gbps
Pour sauvegarder tout ce petit monde : HPE StoreOnce 260 Tb avec Veeam Backup and Replication 9.5 u3

Je vais avoir de quoi m'occuper prochainement! Je "décomissionne" actuellement l'une de nos deux infrastructure VMware afin de tout basculer sur notre infra principale et simplifier la migration future.

[kvm]

Ca va, de quoi t'amuser un petit peu .

[Mimi6666]

Ah oui c'est du lourd !

[jm@rc]

Au sens propre comme au sens figuré
Les cartons commencent à arriver!

[dsebire]

https://techan.fr/problemes-de-performa ... ready.html

attention a bien dimensionner le CPU sur vos VM
appris a mes dépends ce matin.
CPU ready a 40secondes, donc évidement ça rame grave point de vue user !!!!

[jm@rc]

En fait, quand on passe de physique à virtuel, on a tendance à reproduire l'architecture physique en se disant que c'est un dimensionnement bon. Sauf qu'avec les hyperviseurs, l'accès au ressources est bien optimisé. Mettre 1 à 2 CPU(s) est largement suffisant dans bien des cas. Il ne faut pas trop se fier aux préconisations des éditeurs d'applications qui sont restés sur leurs abaques du temps où l'on ne mutualisait pas forcément.

[dsebire]

j'ai passé toutes les VM a 2vcpu (je ne met jamais 1 seul pour éviter la congestion si un process s'emballe)

sauf une VM ou il en faut 4 (calcul...)

j'ai récupéré 40% de cpu (passé de 90% a 50% de charge sur l'hôte lui même)
les VM répondent carrément plus vite !!!

le cpu ready de la pire VM est passé de 60s en crête à 1s

[matteu]

c est absollument pas recommende par vmware la surallocation de cpu car ca provoque l effet inverse donc c est normal que tu y gagnes
pour ma part elles ont toutes 2vcpu mini et les plus grosses un peu plus.
le 2 devient quasi obligatoire a cause des mises a jour... ton serveur devient inutilisable pendant cette periode la sinon...