VMware Global Community
valerio75
Contributor
Contributor

Problema drastico rallentamento VM Windows Server 2008 R2

Buongiorno, ho il seguente problema su una VM Windows Server 2008 R2 STD con 12Vcpu e 40 GB Ram senza RESERVATION ( poi ho verificato che comunque Windows ne vede solo 32GB) su cui mi gira un DB SQL Server e relativo gestionale.

L'infrastruttura è composta da 2 HOST VMWARE Esxi 6.5 in HA , uno con 128 GB ram , l'altro con 80 gb .

Dopo la riapertura dalle vacanze (quindi senza cambiamenti nello specifico sul DB), trovo tutto il sistema notevolmente rallentato , evidenziato anche dal fatto che la %CPU impegnata sul server Windows è costantemente sopra il 70%, dove circa il 50% è SQL Server, mentre in precedenza il carico era attorno al 50% complessivo di media.

L'unico intervento che ho fatto sul Vmware e sulla VM è stato, come consigliato dalle best practice, di aggiornare la compatibilità dalla precedente 5.5 a 6.5  e di provare a ridurre le VCPU assegnate alla VM da 12 a 6  e dal tentativo forzare un HOST FAILURE , per vedere che tutto l'HA funzionasse regolarmente ( test tutto ok), quindo poi ripristinata suddivisione delle varie VM sui 2 host, come in precedenza.

Ecco, a seguito di questo , trovandomi in questa situazione di importante rallentamento, ho ripristinato le VCPU a 12, come in precedenza, ma purtroppo non è cambiato nulla.

Mi resta solo da pensare che queste modifiche/test abbiano cambiato qualcosa nel VMWARE o sulla VM, tale da comportare questa situazione, ma non so come poterlo verificare concretamente.

P.s. Ho notato solo una cosa , che la la RAM è impegnata da monitor di Windows per circa 21 GB, mentre nel monitor della VM appare come "MEMORY Usage" 8,80GB... è normale??

Temendo che per qualche strano motivo fosse entrato in gioco dello SWAP su Windows, ho controllato  e ho notato che il file di Paging era impostato come gestito da "sistema", e al momento aveva allocato 32000 Mb...  non so se puo' essere la causa o una concausa, ma è preferibile "NON IMPOSTARE il FILE DI PAGING" ??

Sottolineo che non ho reservation , nè necessità di condividere risorse, per cui tutte le VM che ho attualmente hanno sufficiente RAM e CPU per funzionare a pieno carico.

Grazie fin da ora a chiunque voglia darmi qualche indicazione per risolvere il problema.

0 Kudos
2 Replies
Giodomi
Hot Shot
Hot Shot

CIao Valerio,

allora prima di tutto è sempre buona cosa quando vedi questo tipo di rallentamenti utilizzare il comando ESXTOP sull'host dove girano le VM che lamentano problemi di performace.
Lo fai via SSH, e da li verifichi per prima cosa i parametri a livello cpu come la % di Ready e Usage.
Ti lascio un articolo interessante che potrebbe esserti utile:ESXTOP – Yellow Bricks | Yellow Bricks

Un altra cosa da verificare, è il NUMA, ovvero gli host quanti socket hanno? e ad ogni socket quanta memoria è effettivamente collegata localmente.
Te lo dico perchè quando si aggiungono più di 8vcpu ad una VM entrano in gioco dinamiche come queste, dove ovviamente le CPU virtuali della VM vanno spalmate al meglio su i core dei processori fisici così come anche la memoria.
altro articolo interessante:
https://vboys.it/vnuma-in-vsphere-6-5/

Ridurre il numero di vCPU al minimo indispensabile è una buona pratica, inoltre, l'HOT ADD della CPU disabilita la possibila di mostrare al Sistema Operativo Guest in questo caso Windows l'effettiva architettura della CPU e della Memoria fisica quindi se hai hot add attivo e vuoi mantenere 12vcpu ti direi di disabilitarlo per vedere se hai qualche beneficio.

Let us Know, se serve scrivi se hai fatto qualche prova Smiley Happy

Ciao
Giovanni

Kudos if it was helpful

GioDomi
0 Kudos
scanda
Expert
Expert

Vm con così tante vCPU e RAM possono dare non pochi problemi, lo scheduler deve trovare le risorse libere da allocare alla VM ad ogni ciclo di schedulazione.

Così ad occhio potrebbee ssere un problema di vNUMA, la tua VM ha un unico socket? è probabile che dividendo le vCPU su 2 socket le cose migliorino.

Da un'occhiata a questo link e prova a fare un pò di troubleshooting

Giovanni ti ha già dato ottimi consigli tra cui quello di verificare proprio il vNUMA, è probabile che con il cambio di vHW siano cambiate proprio queste logiche.

scanda

0 Kudos