Yn dit artikel sille wy prate oer willekeurich tagong ûnthâld (RAM) prestaasje counters yn vSphere.
It liket derop dat mei ûnthâld alles dúdliker is as mei de prosessor: as prestaasjesproblemen ûntsteane op in VM, is it lestich om se net te merken. Mar as se ferskine, is it folle dreger om mei har om te gean. Mar earst dingen earst.
In bytsje teory
De RAM fan firtuele masines wurdt nommen út it ûnthâld fan de tsjinner dêr't de VM's rinne. Dit is frij dúdlik :). As de tsjinner fan RAM is net genôch foar elkenien, begjint ESXi te brûken ûnthâld reclamation techniken. Oars soene de VM-bestjoeringssystemen crashe mei flaters foar RAM-tagong.
ESXi beslút hokker techniken te brûken ôfhinklik fan de RAM-load:
Unthâld status
Border
Aksjes
heech
400% fan minFree
Nei it berikken fan de boppegrins, wurde grutte ûnthâld siden opdield yn lytse (TPS wurket yn standert modus).
Opklearje
100% fan minFree
Grutte ûnthâld siden wurde splitst yn lytse, TPS wurdt twongen.
Sêft
64% fan minFree
TPS + Ballon
Hard
32% fan minFree
TPS + Komprimearje + Ruilje
Leech
16% fan minFree
Komprimearje + Ruilje + Blokkearje
minFree is de RAM nedich foar de hypervisor om te rinnen.
Oant ESXi 4.1 ynklusyf, minFree waard standert fêststeld - 6% fan de tsjinner fan RAM (it persintaazje koe wurde feroare fia de Mem.MinFreePct opsje op ESXi). Yn lettere ferzjes, fanwege de groei fan ûnthâld op tsjinners, begûn minFree wurde berekkene basearre op it bedrach fan ûnthâld fan de host, en net as in fêste persintaazje wearde.
De minFree wearde (standert) wurdt as folget berekkene:
Persintaazje ûnthâld reservearre foar minFree
Unthâld berik
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Oerbleaune ûnthâld
Bygelyks, foar in server mei 128 GB RAM sil de MinFree-wearde as folgjend wêze:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
De werklike wearde kin ferskille mei in pear hûndert MB, ôfhinklik fan de tsjinner en RAM.
Persintaazje ûnthâld reservearre foar minFree
Unthâld berik
Wearde foar 128 GB
6%
0-4 GB
245,76 MB
4%
4-12 GB
327,68 MB
2%
12-28 GB
327,68 MB
1%
Resterend ûnthâld (100 GB)
1024 MB
Typysk, foar produktive tribunes, kin allinich de Hege steat as normaal wurde beskôge. Foar test- en ûntwikkelingsbanken kinne Clear / Soft steaten akseptabel wêze. As de RAM op 'e host minder is dan 64% MinFree, dan hawwe de VM's dy't derop rinne, definityf prestaasjesproblemen.
Yn elke steat wurde bepaalde techniken foar ûnthâldherwinning brûkt, begjinnend fan TPS, dy't praktysk gjin effekt hat op VM-prestaasjes, oant Swapping. Ik sil dy mear oer harren fertelle.
Transparant Page Sharing (TPS). TPS is, rûchwei sprutsen, deduplikaasje fan RAM-siden fan firtuele masines op 'e tsjinner.
ESXi siket identike firtuele masine RAM siden troch in tellen en ferlykje de hash som fan de siden, en ferwideret dûbele siden, ferfangt se mei ferwizings nei deselde side yn de tsjinner syn fysike ûnthâld. As gefolch, fysyk ûnthâld konsumpsje wurdt fermindere en guon ûnthâld oversubscription kin berikt wurde mei praktysk gjin prestaasjes ynfloed.
Dit meganisme wurket allinnich foar ûnthâld siden fan 4 KB yn grutte (lytse siden). De hypervisor besiket net iens siden 2 MB yn grutte te deduplikearjen (grutte siden): de kâns om identike siden fan dizze grutte te finen is net grut.
Standert allocates ESXi ûnthâld oan grutte siden. Splitting fan grutte siden yn lytse siden begjint as de hege steat drompel wurdt berikt en wurdt twongen as de Clear steat wurdt berikt (sjoch de hypervisor steat tabel).
As jo wolle dat TPS begjint te wurkjen sûnder te wachtsjen op 'e host-RAM om fol te wêzen, moatte jo de wearde ynstelle yn Avansearre opsjes ESXi "Mem.AllocGuestLargePage" oant 0 (standert 1). Dan wurdt de tawizing fan grutte ûnthâldsiden foar firtuele masines útskeakele.
Sûnt desimber 2014, yn alle ESXi releases, TPS tusken VMs is standert útskeakele, as in kwetsberens waard fûn dat teoretysk jout ien VM tagong ta de RAM fan in oare VM. Details hjir. Ik bin gjin ynformaasje oer de praktyske ymplemintaasje fan it eksploitearjen fan de TPS-kwetsberens.
TPS-belied wurdt regele fia avansearre opsje "Mem.ShareForceSalting" op ESXi:
0 - Inter-VM TPS. TPS wurket foar siden fan ferskate VM's;
1 - TPS foar VMs mei deselde "sched.mem.pshare.salt" wearde yn VMX;
2 (standert) - Intra-VM TPS. TPS wurket foar siden binnen in VM.
It makket perfoarst sin om grutte siden út te skeakeljen en Inter-VM TPS yn te skeakeljen op testbanken. Dit kin ek brûkt wurde foar stands mei in grut oantal ferlykbere VM's. Bygelyks, op tribunes mei VDI, besparring yn fysike ûnthâld kin berikke tsientallen prosint.
Memory Ballooning. Ballonfarren is net langer sa'n harmless en transparante technyk foar it VM-bestjoeringssysteem as TPS. Mar as jo goed brûkt wurde, kinne jo libje en sels wurkje mei Ballooning.
Tegearre mei Vmware Tools is in spesjale stjoerprogramma neamd Balloon Driver (aka vmmemctl) ynstalleare op 'e VM. Doe't de hypervisor begjint te rinne út fysyk ûnthâld en komt yn 'e Soft steat, freget ESXi de VM in weromsette net brûkte RAM fia dizze Balloon Driver. De bestjoerder, op syn beurt, wurket op it bestjoeringssysteem nivo en freget fergees ûnthâld fan it. De hypervisor sjocht hokker siden fan fysyk ûnthâld de Balloon Driver hat beset, nimt ûnthâld fan 'e firtuele masine en jout it werom nei de host. D'r binne gjin problemen mei de wurking fan it OS, om't op OS-nivo it ûnthâld wurdt beset troch de Balloon Driver. Standert kin Balloon Driver oant 65% fan VM-ûnthâld nimme.
As VMware-ark net binne ynstalleare op 'e VM of Ballooning is útskeakele (ik advisearje it net, mar d'r is :), de hypervisor skeakelt fuortendaliks nei strangere techniken foar it fuortheljen fan ûnthâld. Konklúzje: soargje derfoar dat VMware-ark binne op 'e VM.
De wurking fan Balloon Driver kin wurde kontrolearre fanút it OS fia VMware Tools.
Unthâld kompresje. Dizze technyk wurdt brûkt as ESXi berikt de Hard steat. Lykas de namme al fermoeden docht, besiket ESXi in 4KB-side fan RAM te komprimearjen yn 2KB, en dêrmei wat romte frij te meitsjen yn it fysike ûnthâld fan 'e tsjinner. Dizze technyk fergruttet de tagongstiid foar de ynhâld fan VM RAM-siden signifikant, om't de side earst moat wurde dekomprimearre. Soms kinne net alle siden komprimearre wurde en nimt it proses sels wat tiid. Dêrom, dizze technyk is net hiel effektyf yn de praktyk.
Unthâld Swapping. Nei in koarte faze fan Unthâld kompresje, ESXi hast ûnûntkomber (as de VMs hawwe net ferhuze nei oare hosts of binne net útskeakele) oerstap nei Swapping. En as d'r heul min ûnthâld oer is (Low state), dan hâldt de hypervisor ek op mei it tawizen fan ûnthâldsiden oan 'e VM, wat problemen kinne feroarsaakje yn' e gast OS fan 'e VM.
Dit is hoe't Swapping wurket. As jo in firtuele masine ynskeakelje, wurdt der in bestân mei in .vswp-útwreiding foar makke. It is yn grutte gelyk oan de net-reservearde RAM fan 'e VM: dit is it ferskil tusken konfigureare en reservearre ûnthâld. Wannear't Ruilje rint, ruilet ESXi firtuele masine ûnthâld siden yn dizze triem en begjint te wurkjen mei it ynstee fan de tsjinner syn fysike ûnthâld. Fansels, sa'n "RAM" ûnthâld ferskate oarders fan grutte stadiger as echte ûnthâld, sels as de .vswp is op flugge opslach.
Oars as Ballooning, as net brûkte siden wurde nommen út in VM, mei Swapping siden dy't aktyf brûkt wurde troch it OS of applikaasjes binnen de VM kinne wurde ferpleatst nei skiif. As gefolch, de prestaasjes fan 'e VM sakket oant it befriezen. De VM wurket formeel en kin op syn minst goed útskeakele wurde fan it OS. As jo geduld binne 😉
As VM's nei Swap gien binne, is dit in needsituaasje dy't as mooglik it bêste foarkomt.
Basic firtuele masine ûnthâld prestaasjes counters
Sa kamen wy by it wichtichste ding. Om de ûnthâldstatus fan 'e VM te kontrolearjen, binne d'r de folgjende tellers:
aktyf - toant it bedrach fan RAM (KB) dat de VM tagong hat yn 'e foarige mjitperioade.
Brûken - itselde as Aktyf, mar as in persintaazje fan 'e konfigureare RAM fan' e VM. Berekkene mei de folgjende formule: aktyf ÷ firtuele masine ynsteld ûnthâld grutte.
Heech gebrûk en aktyf, respektivelik, binne net altyd in yndikator fan VM-prestaasjesproblemen. As de VM agressyf gebrûk fan ûnthâld (op syn minst tagong ta it), betsjut dit net dat d'r net genôch ûnthâld is. Dit is leaver in reden om te sjen nei wat der bart yn it OS.
D'r is in standert alarm foar ûnthâldgebrûk foar VM's:
Shared - it bedrach fan VM RAM deduplisearre mei TPS (binnen in VM as tusken VM's).
Tawiisd - it bedrach fan host fysyk ûnthâld (KB) dat waard tawiisd oan de VM. Aktivearret Shared.
Ferbrûkt (Granted - Shared) - it bedrach fan fysyk ûnthâld (KB) dat de VM konsumearret fan 'e host. Omfettet gjin Shared.
As in part fan it VM ûnthâld wurdt jûn net út de host syn fysike ûnthâld, mar út in swap triem, of ûnthâld wurdt nommen út de VM fia de Balloon Driver, dit bedrach wurdt net rekken holden yn ferliend en konsumearre.
Hege ferliend en konsumearre wearden binne folslein normaal. It bestjoeringssysteem nimt stadichoan ûnthâld fan 'e hypervisor en jout it net werom. Yn 'e rin fan' e tiid, yn in aktyf rinnende VM, benaderje de wearden fan dizze tellers de hoemannichte konfigureare ûnthâld, en bliuwe dêr.
Nul - it bedrach fan VM RAM (KB), dat befettet nullen. Sok ûnthâld wurdt beskôge as fergees troch de hypervisor en kin jûn wurde oan oare firtuele masines. Neidat de gast OS hat skreaun wat oan nul ûnthâld, it giet yn Consumed en net werom werom.
Reservearre Overhead - it bedrach fan VM RAM, (KB) reservearre troch de hypervisor foar VM operaasje. Dit is in lyts bedrach, mar it moat beskikber wêze op de host, oars sil de VM net begjinne.
Ballon - it bedrach fan RAM (KB) fuortsmiten fan de VM mei help fan Balloon Driver.
Komprimeare - it bedrach fan RAM (KB) dat waard komprimearre.
Omruile - it bedrach fan RAM (KB), dy't, troch it gebrek oan fysyk ûnthâld op 'e tsjinner, ferhuze nei skiif.
Ballon en oare ûnthâld reclamation techniken tellers binne nul.
Dit is hoe't de grafyk derút sjocht mei de Unthâldtellers fan in normaal wurkjende VM mei 150 GB RAM.
Yn 'e grafyk hjirûnder hat de VM dúdlike problemen. Under de grafyk kinne jo sjen dat foar dizze VM alle beskreaune techniken foar wurkjen mei RAM waarden brûkt. Ballon foar dizze VM is folle grutter as Consumed. Yn feite, VM is mear dea as libben.
ESXTOP
Lykas by de CPU, as wy de situaasje op 'e host fluch beoardielje wolle, lykas har dynamyk mei in ynterval fan maksimaal 2 sekonden, moatte wy ESXTOP brûke.
It ESXTOP Memory-skerm wurdt oproppen mei de "m"-kaai en sjocht der sa út (fjilden B, D, H, J, K, L, O selektearre):
De folgjende parameters sille ús ynteressearje:
Mem overcommit gem - gemiddelde wearde fan ûnthâld oerabonnemint op de host foar 1, 5 en 15 minuten. As it boppe nul is, dan is dit in reden om te sjen nei wat der bart, mar net altyd in yndikator fan problemen.
Yn rigels PMEM/MB и VMKMEM/MB - ynformaasje oer it fysike ûnthâld fan 'e tsjinner en it ûnthâld beskikber foar de VMkernel. Under de nijsgjirrige dingen hjir kinne jo sjen de minfree wearde (yn MB), de host steat yn it ûnthâld (yn ús gefal, heech).
In line NUMA/MB Jo kinne de ferdieling fan RAM sjen oer NUMA-knooppunten (sockets). Yn dit foarbyld is de ferdieling unjildich, wat yn prinsipe net hiel goed is.
It folgjende is algemiene serverstatistiken foar techniken foar ûnthâldherwinning:
PSHARE/MB - dit binne TPS-statistiken;
SWAP/MB - Ruilje gebrûksstatistiken;
ZIP/MB - statistyk foar kompresje fan ûnthâldside;
MEMCTL/MB - Statistiken oer gebrûk fan ballonbestjoerder.
Foar yndividuele VM's kinne wy ynteressearre wêze yn 'e folgjende ynformaasje. Ik haw de nammen fan de VM's ferburgen om it publyk net te betize :). As de ESXTOP-metryske is fergelykber mei de teller yn vSphere, sil ik de oerienkommende teller leverje.
MEMSZ - hoemannichte ûnthâld konfigurearre op de VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + ûnoantaaste.
SUBSYDZJE - Ferjûn yn MB.
TCHD - Aktyf yn MByte.
MCTL? - oft Balloon Driver is ynstallearre op de VM.
MCTLSZ - Ballon nei MB.
MCTLGT - it bedrach fan RAM (MBytes) dat ESXi wol fuortsmite fan de VM fia de Balloon Driver (Memctl Target).
MCTLMAX - it maksimum bedrach fan RAM (MBytes) dat ESXi kin fuortsmite fan in VM fia de Balloon Driver.
SWCUR - it hjoeddeistige bedrach fan RAM (MBytes) tawiisd oan 'e VM út it Swap-bestân.
S.W.G.T. - it bedrach fan RAM (MBytes) dat ESXi wol jaan oan de VM út de Swap triem (Swap Target).
Jo kinne ek mear detaillearre ynformaasje besjen oer de NUMA-topology fan 'e VM fia ESXTOP. Om dit te dwaan, selektearje fjilden D, G:
LYTS - NUMA-knooppunten wêrop de VM leit. Hjir kinne jo daliks breed vm fernimme, dy't net passe op ien NUMA-knooppunt.
NRMEM - hoefolle megabytes ûnthâld nimt de VM fan it NUMA-knooppunt op ôfstân.
NLMEM - hoefolle megabytes ûnthâld de VM nimt fan it lokale NUMA-knooppunt.
N%L - persintaazje fan VM-ûnthâld op it lokale NUMA-knooppunt (as minder dan 80%, kinne prestaasjesproblemen ûntstean).
Unthâld op de hypervisor
As CPU-tellers foar in hypervisor meastentiids net fan bysûnder belang binne, dan is de situaasje mei ûnthâld it tsjinoerstelde. High Memory Usage op in VM jout net altyd in prestaasje probleem, mar hege Memory Usage op in hypervisor trigger ûnthâld behear techniken en feroarsaket problemen mei VM prestaasjes. Jo moatte alaarms foar gebrûk fan hostûnthâld kontrolearje en foarkomme dat VM's yn Swap komme.
Unswap
As in VM wurdt fongen yn Swap, syn prestaasje wurdt gâns fermindere. Spoaren fan Ballooning en kompresje ferdwine fluch neidat frije RAM ferskynt op 'e host, mar de firtuele masine hat gjin haast om werom te kommen fan Swap nei de RAM fan' e tsjinner.
Foardat ESXi 6.0 wie de ienige betroubere en rappe manier om in VM fan Swap te ferwiderjen om te herstarten (krekterder, útskeakelje / oansette de kontener). Begjin mei ESXi 6.0, hoewol net hielendal offisjeel, is in wurkjende en betroubere manier ferskynd om in VM fan Swap te ferwiderjen. Op ien fan 'e konferinsjes koe ik prate mei ien fan' e VMware-yngenieurs ferantwurdlik foar CPU Scheduler. Hy befêstige dat de metoade frij wurket en feilich is. Yn ús ûnderfining wiene der ek gjin problemen mei.
De eigentlike kommando's foar it fuortheljen fan in VM fan Swap Duncan Eppinga. Ik sil de detaillearre beskriuwing net werhelje, ik sil gewoan in foarbyld jaan fan it gebrûk. Lykas jo kinne sjen yn 'e skermôfbylding, ferdwynt in skoft nei it útfieren fan it opjûne kommando Swap op' e VM.
Tips foar it behearen fan RAM op ESXi
As lêste, hjir binne in pear tips dy't jo sille helpe om problemen mei VM-prestaasjes te foarkommen fanwege RAM:
- Foarkom oerabonnemint fan RAM yn produktive klusters. It is oan te rieden om altyd ~ 20-30% fan it frije ûnthâld yn it kluster te hawwen, sadat DRS (en de behearder) romte hawwe om te manoeuvreerjen en VM's net nei Swap gean by migraasje. Ferjit ek net oer de marzje foar fouttolerânsje. It is onaangenaam as, as ien tsjinner mislearret en de VM wurdt opnij opstarte mei HA, guon fan 'e masines ek gean nei Swap.
- Yn tige konsolidearre ynfrastruktuer, besykje NET VM's te meitsjen mei ûnthâld grutter dan de helte fan it hostûnthâld. Dit sil DRS wer helpe om firtuele masines te fersprieden oer klusterservers sûnder problemen. Dizze regel is fansels net universeel :).
- Pas op foar Host Memory Usage Alarm.
- Ferjit net VMware Tools op 'e VM te ynstallearjen en Ballooning net útsette.
- Tink oan it ynskeakeljen fan Inter-VM TPS en it útskeakeljen fan Grutte siden yn VDI- en testomjouwings.
- As de VM prestaasjesproblemen ûnderfynt, kontrolearje dan oft it ûnthâld brûkt fan in NUMA-knooppunt op ôfstân.
- Ferwiderje VM's fan Swap sa rap mooglik! Under oare dingen, as de VM yn Swap is, lijt it opslachsysteem foar fanselssprekkende redenen.
Dat is alles foar my oer RAM. Hjirûnder binne relatearre artikels foar dyjingen dy't djipper wolle gean. It folgjende artikel sil wijd wurde oan storj.
Nuttige keppelings
Boarne: www.habr.com