Mät innan du ändrar
Prestandaproblem i VMware ESXi beror sällan på en enda orsak. En virtuell maskin kan kännas långsam på grund av CPU-kö, minnestryck, hög lagringslatens, fel nätverksdesign eller en kombination av flera mindre problem. Därför bör felsökning börja med mätning. Att ge varje VM fler vCPU:er och mer minne kan ibland göra situationen sämre, eftersom schemaläggaren får svårare att placera resurser effektivt.
En bra prestandarutin börjar med baslinjer. Dokumentera hur värden ser ut när miljön fungerar normalt: CPU-ready, minnesballooning, swap, datastore latency, nätverksfel och genomsnittlig belastning. När användare senare rapporterar problem kan du jämföra med normalvärden i stället för att gissa. Verktyg som vSphere Performance Charts, esxtop och övervakningssystem från tredje part ger olika perspektiv och bör användas tillsammans.
CPU och NUMA
CPU-ready är ett centralt mått i ESXi. Det visar hur länge en virtuell CPU väntar på att få köras på fysisk CPU. Höga värden kan tyda på överbelastning, för många vCPU:er eller dålig dimensionering. En vanlig missuppfattning är att en VM alltid blir snabbare med fler vCPU:er. I praktiken bör en VM bara få så många vCPU:er som arbetslasten faktiskt kan använda. Annars ökar konkurrensen och schemaläggningen blir mindre effektiv.
NUMA spelar också stor roll på moderna servrar. Om en VM är större än en NUMA-nod kan minnesåtkomst bli långsammare eftersom CPU och minne inte längre är lika lokala. För databaser och andra känsliga arbetslaster bör administratören förstå serverns CPU-socklar, kärnor och minneslayout. VMware ESXi kan hantera mycket automatiskt, men rätt dimensionering från början gör att hypervisorn får bättre förutsättningar.
När du planerar en ny miljö är det klokt att läsa in dig på versioner och kompatibilitet. Vår startsida om VMware ESXi download ger en översikt över hur man bör tänka, men själva produktinformationen ska alltid verifieras hos officiella Broadcom- eller VMware-källor.
Minne och överallokering
ESXi kan hantera minne effektivt, men minne är fortfarande en fysisk begränsning. Om värden börjar använda swap på hostnivå kan prestanda falla kraftigt. Ballooning kan vara acceptabelt i korta perioder, men återkommande ballooning visar ofta att värden är för hårt belastad eller att virtuella maskiner har fått mer minne än de behöver. Reserveringar kan skydda kritiska system, men för många reservationer kan minska flexibiliteten i klustret.
Rätt storlek på VM:ar är därför en löpande uppgift. Följ faktisk användning över tid och justera i små steg. En filserver, en domänkontrollant och en databasserver har olika mönster. En statisk mall för alla VM:ar leder ofta till slöseri och sämre kapacitetsplanering. Bra prestanda handlar om att matcha resurser mot arbetslast, inte om att maximera varje inställning.
Lagring och nätverk
Lagringslatens är en av de vanligaste orsakerna till långsam virtualisering. Kontrollera latens på datastore-nivå, ködjup, pathing och hur backupfönster påverkar I/O. Snapshots som lämnas kvar för länge kan också skapa problem. De är användbara vid korta förändringar, men ska inte ersätta backup och bör inte bli permanenta.
Nätverksprestanda påverkas av uplinks, VLAN, drivrutiner och hur portgrupper är konfigurerade. Separera management, VM-trafik, lagring och vMotion när miljön kräver det. Kontrollera felräknare på fysiska switchar och NIC:ar, inte bara i vSphere. En ESXi-värd kan rapportera normal belastning samtidigt som en fysisk länk tappar paket eller förhandlar fel hastighet.
En metodisk optimering
Det bästa sättet att optimera VMware ESXi är att arbeta metodiskt: mät, ändra en sak, följ upp och dokumentera resultatet. Undvik stora ändringar utan tydlig hypotes. Om flera VM:ar är långsamma samtidigt är problemet ofta på host-, lagrings- eller nätverksnivå. Om bara en VM är långsam kan orsaken finnas i gästoperativsystemet, applikationen eller dess resursprofil. Den disciplinen sparar tid och minskar risken för att nya problem skapas under felsökningen.