Optimization: Azure VM performance tuning - size families, accelerated networking, caching and placement

#1. Size family and generation

Newer generations usually give more performance per vCPU at similar or lower price. When VMs are on old generations (v2/v3), test a move to a current one. It's a resize (reboot), sometimes needing a deallocate if the hardware cluster doesn't support the new size.

az vm list-vm-resize-options -g rg-app -n app01 -o table
az vm resize -g rg-app -n app01 --size Standard_D4s_v5

Check the target size supports what you rely on: premium storage (s in the name), local temp disk (some newer sizes have none), accelerated networking, and the max data disk count.

#2. B-series credit exhaustion

B-series VMs look fine for weeks, then run at baseline CPU when credits run out.

az monitor metrics list --resource <vm-id> --metric "CPU Credits Remaining" --interval PT1H --offset 7d -o table

If credits hit zero regularly, the workload isn't bursty. Move it to a D-series.

#3. Accelerated networking

Lower latency and jitter, higher packets per second, less CPU on networking. Check and enable:

az network nic show -g rg-app -n app01-nic --query enableAcceleratedNetworking
az vm deallocate -g rg-app -n app01
az network nic update -g rg-app -n app01-nic --accelerated-networking true
az vm start -g rg-app -n app01

Inside the guest, confirm the Mellanox/MANA virtual function is present (lspci on Linux, Device Manager on Windows) and drivers are current.

#4. Disk host caching

Changing caching on a data disk briefly detaches it from the guest's point of view; schedule it.

az vm update -g rg-sql -n sql01 --disk-caching 0=ReadOnly 1=None

#5. Placement for latency-sensitive tiers

• App and database tiers in the same region and, where possible, the same zone for chatty traffic (balance against HA design).
• Proximity placement groups for the lowest latency between specific VMs (e.g. SAP app servers and database). They reduce placement flexibility, so allocation failures are more likely on resize.

#6. Right-sizing with Advisor and metrics

Azure Advisor flags low-utilisation VMs. Confirm with 30 days of data before resizing:

InsightsMetrics
| where TimeGenerated > ago(30d) and Namespace == "Processor" and Name == "UtilizationPercentage"
| summarize p95_cpu = percentile(Val, 95) by Computer
| join kind=inner (
    InsightsMetrics
    | where TimeGenerated > ago(30d) and Namespace == "Memory" and Name == "AvailableMB"
    | summarize min_avail_mb = min(Val) by Computer) on Computer
| order by p95_cpu asc

Low p95 CPU and plenty of available memory → candidate for a smaller size. Memory-bound VMs may need an E-series of the same vCPU count instead.

#7. OS-level quick wins

• Windows: power plan High performance; current Hyper-V/Azure guest drivers; Defender exclusions for database files per vendor guidance.
• Linux: current kernel and Azure-tuned images; tuned profile (virtual-guest or vendor-specific); check /etc/fstab uses nofail for data disks.
• Both: temp disk for page/swap file where the size has one (data on it is lost on redeploy).

Tip

Change one thing at a time and measure (latency, CPU, IOPS) for a few days. Combining a resize, caching change and driver update makes it impossible to know which one helped, or which one hurt.

#Checklist

• VMs on current-generation sizes that fit the workload
• No B-series VMs running out of credits
• Accelerated networking enabled and verified in guest
• Host caching set per disk role
• Placement reviewed for chatty tiers
• Advisor recommendations confirmed with 30-day metrics