VMware best practices: CPU tuning

Questo genere di post potrebbero diventare una rubrica: VMware best practices, cosa è bene fare e cosa è meglio evitare in un sistema VMware? Un passo alla volta. Oggi dedichiamoci al tuning delle CPU, anzi delle Virtual CPU. Innanzi tutto citiamo l’autorevole fonte di questo post, VI Performance Tuning, documento che dovrebbe essere letto da tutti gli addetti ai lavori (tutti quelli che dicono che le VMs sono lente devono leggerlo due volte). La prima parte della risorsa è dedicata al tuning delle CPU e di seguito la voglio analizzare pezzo a pezzo.

When configuring virtual machines, remember that ESX Server itself has some overhead. Allow for the CPU overhead required by virtualization, and take care not to excessively overcommit processor resources (in terms of CPU utilizations and the total number of VCPUs).

Il virtual hardware ha un “costo” che chiamiamo overhead. Abbondare nell’assegnazione delle risorse non serve a nulla e aumenta il costo che VMware dovrà sostenere per virtualizzare la nostra macchina. La cosa migliore da fare è assegnare il corretto quantitativo di risorse, in questo caso di virtual CPU.

Use as few virtual CPUs (VCPUs) as possible. Do not use virtual SMP if your application is single threaded and does not benefit from the additional VCPUs, for example.

Rafforziamo il precedente concetto ricordandoci che, se l’applicazione non supporta il multi threading è inutile creare una VM con più processori. Il consiglio è chiaro: usate il minor numero di CPU possibile.

Make sure to configure a single-processor virtual machine with a UP HAL/kernel. Multi-processor virtual machines must be configured with an SMP HAL/kernel.

Questo è buon senso e non saprei come spiegarlo più semplicemente di così come esposto.

Avoid running programs in the service console that consume excessive amounts of CPU or memory. This can adversely affect performance of the virtual machines and ESX Server. It is a good idea to periodically monitor service console memory and CPU usage using esxtop.

Teniamo a mente che la service console (non più presente in vSphere 5) è a tutti gli effetti una macchina virtuale, utile all’interfacciamento con l’hypervisor, e che utilizza le risorse dello stesso. Un eccessivo utilizzo di risorse da parte della service console può avere impatto sulle performance delle VMs che risiedono sull’host.

Monitor idle loop spin parameter: certain guest operating systems do not actually halt the virtual CPU when they idle. Since the virtual CPU is not halted, ESX will continue to run and schedule this virtual CPU as if it were still doing useful work. This execution of the idle loop results in unnecessary CPU consumption. To prevent such unneeded CPU consumption, ESX detects that a guest VCPU is attempting to idle and deschedules it. The detection heuristic is controlled by the idle loop spin parameter and can sometimes affect performance. For more details on optimally configuring this parameter, please refer to KB article 1730.

Può capitare che una VM abbia le virtual CPU in stato di idle a livello guest ma non a livello host. Questo stato inconsistente porta ad uno spreco di risorse in quanto per ESX la CPU in oggetto sta di fatto lavorando. Per arginare questo comportamento è necessario provvedere alla corretta configurazione di alcuni parametri come specificato nella KB 1730.

Sono pochi ma vitali suggerimenti che, ho avuto modo di appurare personalmente, hanno impatto positivo sulle architettura VMware.