Šajā rakstā mēs runāsim par brīvpiekļuves atmiņas (RAM) veiktspējas skaitītājiem vSphere.
Šķiet, ka ar atmiņu viss ir skaidrāk nekā ar procesoru: ja VM rodas veiktspējas problēmas, ir grūti tās nepamanīt. Bet, ja tie parādās, ar tiem tikt galā ir daudz grūtāk. Bet vispirms vispirms.
Mazliet teorija
Virtuālo mašīnu operatīvā atmiņa tiek ņemta no tā servera atmiņas, kurā darbojas virtuālās mašīnas. Tas ir diezgan pašsaprotami :). Ja servera RAM visiem nepietiek, ESXi sāk izmantot atmiņas atgūšanas paņēmienus. Pretējā gadījumā VM operētājsistēmas avarēs ar RAM piekļuves kļūdām.
ESXi izlemj, kuras metodes izmantot atkarībā no RAM slodzes:
Atmiņas statuss
Robeža
Aktivitāte
augsts
400% no minFree
Pēc augšējās robežas sasniegšanas lielas atmiņas lapas tiek sadalītas mazās (TPS darbojas standarta režīmā).
skaidrs
100% no minFree
Lielās atmiņas lapas tiek sadalītas mazās, TPS tiek piespiests.
Mīksts
64% no minFree
TPS + balons
Grūti
32% no minFree
TPS + Compress + Swap
Zems
16% no minFree
Saspiest + apmainīt + bloķēt
minFree ir RAM, kas nepieciešama hipervizora darbībai.
Līdz ESXi 4.1 (ieskaitot) minFree tika fiksēts pēc noklusējuma — 6% no servera RAM (procentuālo daļu var mainīt, izmantojot ESXi opciju Mem.MinFreePct). Vēlākās versijās serveru atmiņas pieauguma dēļ minFree sāka aprēķināt, pamatojoties uz resursdatora atmiņas apjomu, nevis kā fiksētu procentuālo vērtību.
MinFree vērtība (noklusējums) tiek aprēķināta šādi:
MinFree rezervētās atmiņas procentuālā daļa
Atmiņas diapazons
6%
0–4 GB
4%
4–12 GB
2%
12–28 GB
1%
Atlikusī atmiņa
Piemēram, serverim ar 128 GB RAM MinFree vērtība būs šāda:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
Faktiskā vērtība var atšķirties par pāris simtiem MB atkarībā no servera un RAM.
MinFree rezervētās atmiņas procentuālā daļa
Atmiņas diapazons
Vērtība 128 GB
6%
0–4 GB
245,76 MB
4%
4–12 GB
327,68 MB
2%
12–28 GB
327,68 MB
1%
Atlikusī atmiņa (100 GB)
1024 MB
Parasti produktīvām audzēm par normālu var uzskatīt tikai augsto stāvokli. Testēšanas un izstrādes stendiem var būt pieņemami Clear/Soft statuss. Ja resursdatora operatīvā atmiņa ir mazāka par 64% MinFree, tad tajā darbojošās virtuālās mašīnas noteikti saskaras ar veiktspējas problēmām.
Katrā stāvoklī tiek izmantotas noteiktas atmiņas atjaunošanas metodes, sākot no TPS, kas praktiski neietekmē VM veiktspēju, un beidzot ar apmaiņu. Es jums pastāstīšu vairāk par viņiem.
Caurspīdīga lapu koplietošana (TPS). TPS, rupji runājot, ir servera virtuālo mašīnu RAM lapu dublēšana.
ESXi meklē identiskas virtuālās mašīnas RAM lapas, saskaitot un salīdzinot lapu jaucējsummas, un noņem dublētās lapas, aizstājot tās ar atsaucēm uz to pašu lapu servera fiziskajā atmiņā. Tā rezultātā tiek samazināts fiziskās atmiņas patēriņš, un zināmu atmiņas pārsniegšanu var panākt, praktiski neietekmējot veiktspēju.
Šis mehānisms darbojas tikai atmiņas lapām, kuru izmērs ir 4 KB (mazas lapas). Hipervizors pat nemēģina dedublēt 2 MB lielas lapas (lielas lapas): iespēja atrast identiskas šāda izmēra lapas nav liela.
Pēc noklusējuma ESXi piešķir atmiņu lielām lapām. Lielu lappušu sadalīšana mazās lapās sākas, kad tiek sasniegts augstais stāvokļa slieksnis, un tiek piespiedu kārtā, kad tiek sasniegts notīrīšanas stāvoklis (skatiet hipervizora stāvokļa tabulu).
Ja vēlaties, lai TPS sāktu darboties, negaidot, kamēr resursdatora RAM būs pilna, jums ir jāiestata vērtība sadaļā Advanced Options ESXi “Mem.AllocGuestLargePage” uz 0 (noklusējuma 1). Tad lielu atmiņas lapu piešķiršana virtuālajām mašīnām tiks atspējota.
Kopš 2014. gada decembra visos ESXi laidienos TPS starp virtuālajām mašīnām pēc noklusējuma ir atspējots, jo tika atrasta ievainojamība, kas teorētiski ļauj vienai VM piekļūt citas virtuālās mašīnas operatīvajai atmiņai. Sīkāka informācija šeit. Neesmu saskāries ar informāciju par TPS ievainojamības izmantošanas praktisko ieviešanu.
TPS politika tiek kontrolēta, izmantojot papildu opciju “Mem.ShareForceSalting” uz ESXi:
0 — Inter-VM TPS. TPS darbojas dažādu virtuālo mašīnu lapām;
1 – TPS virtuālajām mašīnām ar tādu pašu “sched.mem.pshare.salt” vērtību VMX;
2 (noklusējums) — VM iekšējais TPS. TPS darbojas lapām virtuālajā mašīnā.
Noteikti ir lietderīgi testa stendos atspējot lielas lapas un iespējot Inter-VM TPS. To var izmantot arī stendiem ar lielu skaitu līdzīgu virtuālo mašīnu. Piemēram, uz stendiem ar VDI ietaupījums fiziskajā atmiņā var sasniegt vairākus desmitus procentu.
Atmiņas balonēšana. Balonēšana vairs nav tik nekaitīgs un caurspīdīgs paņēmiens VM operētājsistēmai kā TPS. Bet, ja to lieto pareizi, jūs varat dzīvot un pat strādāt ar Ballooning.
Kopā ar Vmware Tools virtuālajā mašīnā ir instalēts īpašs draiveris ar nosaukumu Balloon Driver (aka vmmemctl). Kad hipervizoram sāk beigties fiziskā atmiņa un tas pāriet uz mīksto stāvokli, ESXi lūdz virtuālo mašīnu atgūt neizmantoto RAM, izmantojot šo balona draiveri. Draiveris savukārt strādā operētājsistēmas līmenī un pieprasa no tā brīvu atmiņu. Hipervizors redz, kuras fiziskās atmiņas lapas balona draiveris ir aizņēmis, paņem atmiņu no virtuālās mašīnas un atgriež to resursdatoram. Ar OS darbību nav problēmu, jo OS līmenī atmiņu aizņem Balloon Driver. Pēc noklusējuma Balloon Driver var aizņemt līdz 65% no virtuālās mašīnas atmiņas.
Ja VM nav instalēti VMware rīki vai Ballooning ir atspējots (es to neiesaku, bet ir :), hipervizors uzreiz pāriet uz stingrākiem atmiņas noņemšanas paņēmieniem. Secinājums: pārliecinieties, vai virtuālajā mašīnā ir pieejami VMware rīki.
Balloon Driver darbību var pārbaudīt no operētājsistēmas, izmantojot VMware Tools.
Atmiņas saspiešana. Šo paņēmienu izmanto, kad ESXi sasniedz cieto stāvokli. Kā norāda nosaukums, ESXi mēģina saspiest 4 KB RAM lappusi 2 KB, tādējādi atbrīvojot vietu servera fiziskajā atmiņā. Šis paņēmiens ievērojami palielina piekļuves laiku VM RAM lapu saturam, jo lapa vispirms ir jāatspiež. Dažreiz visas lapas nevar saspiest, un pats process aizņem kādu laiku. Tāpēc praksē šī tehnika nav īpaši efektīva.
Atmiņas maiņa. Pēc īsas atmiņas saspiešanas fāzes ESXi gandrīz neizbēgami (ja virtuālās mašīnas nav pārvietotas uz citiem resursdatoriem vai nav izslēgtas) pārslēdzas uz apmaiņu. Un, ja ir atlicis ļoti maz atmiņas (zems stāvoklis), hipervizors arī pārtrauc atmiņas lapu piešķiršanu virtuālajam datoram, kas var radīt problēmas VM viesu OS.
Šādi darbojas apmaiņa. Ieslēdzot virtuālo mašīnu, tai tiek izveidots fails ar paplašinājumu .vswp. Tā ir vienāda ar virtuālās mašīnas nerezervēto RAM lielumu: šī ir atšķirība starp konfigurēto un rezervēto atmiņu. Kad darbojas Swapping, ESXi apmaina virtuālās mašīnas atmiņas lapas šajā failā un sāk strādāt ar to, nevis servera fizisko atmiņu. Protams, šāda “RAM” atmiņa ir par vairākām kārtām lēnāka nekā reālā atmiņa, pat ja .vswp ir ātrajā krātuvē.
Atšķirībā no Ballooning, kad neizmantotās lapas tiek ņemtas no virtuālās mašīnas, ar apmaiņu lapas, kuras aktīvi izmanto OS vai lietojumprogrammas virtuālajā mašīnā, var pārvietot uz disku. Tā rezultātā VM veiktspēja samazinās līdz sasalšanas punktam. Virtuālā mašīna formāli darbojas, un vismaz to var pareizi atspējot no OS. Ja esi pacietīgs 😉
Ja virtuālās mašīnas ir pārgājušas uz Swap, šī ir ārkārtas situācija, no kuras vislabāk izvairīties, ja iespējams.
Pamata virtuālās mašīnas atmiņas veiktspējas skaitītāji
Tātad mēs nonācām pie galvenā. Lai pārraudzītu VM atmiņas stāvokli, ir šādi skaitītāji:
Aktīvs — parāda RAM apjomu (KB), kuram virtuālā mašīna piekļuva iepriekšējā mērījumu periodā.
Lietošana — tas pats, kas Active, bet procentos no virtuālās mašīnas konfigurētās RAM. Aprēķināts, izmantojot šādu formulu: aktīvā ÷ virtuālās mašīnas konfigurētās atmiņas lielums.
Attiecīgi High Usage un Active ne vienmēr liecina par VM veiktspējas problēmām. Ja VM agresīvi izmanto atmiņu (vismaz tai piekļūst), tas nenozīmē, ka nav pietiekami daudz atmiņas. Drīzāk tas ir iemesls paskatīties uz to, kas notiek OS.
VM ir standarta trauksmes signāls par atmiņas izmantošanu:
Dalījās — VM RAM apjoms, kas dedublēts, izmantojot TPS (VM ietvaros vai starp virtuālajām mašīnām).
Piešķirts — resursdatora fiziskās atmiņas (KB) apjoms, kas tika piešķirts VM. Iespējo kopīgoto.
Patērēts (Piešķirts — koplietots) — fiziskās atmiņas apjoms (KB), ko VM patērē no resursdatora. Neietver koplietoto.
Ja daļa no virtuālās mašīnas atmiņas tiek piešķirta nevis no resursdatora fiziskās atmiņas, bet no mijmaiņas faila vai atmiņa tiek ņemta no virtuālās mašīnas, izmantojot Balloon Driver, šī summa netiek ņemta vērā sadaļā Piešķirtais un patērētais.
Augstas piešķirtās un patērētās vērtības ir pilnīgi normālas. Operētājsistēma pakāpeniski paņem atmiņu no hipervizora un neatdod to. Laika gaitā aktīvi darbojošā virtuālajā mašīnā šo skaitītāju vērtības tuvojas konfigurētās atmiņas apjomam un paliek tur.
Nulle — VM RAM apjoms (KB), kurā ir nulles. Hipervizors šādu atmiņu uzskata par brīvu, un to var piešķirt citām virtuālajām mašīnām. Pēc tam, kad viesu operētājsistēma ir kaut ko ierakstījusi nulles atmiņai, tā nonāk mapē Consumed un neatgriežas.
Rezervēts pieskaitāmās izmaksas — VM RAM apjoms (KB), ko hipervizors rezervējis VM darbībai. Tā ir neliela summa, taču tai jābūt pieejamai resursdatorā, pretējā gadījumā virtuālā mašīna netiks startēta.
Balons — RAM apjoms (KB), kas noņemts no virtuālās mašīnas, izmantojot Balloon Driver.
Saspiests — saspiestās RAM apjoms (KB).
Nomainīju — RAM apjoms (KB), kas fiziskās atmiņas trūkuma dēļ serverī tika pārvietots uz disku.
Balonu un citu atmiņas atjaunošanas metožu skaitītāji ir nulle.
Šādi izskatās grafiks ar parasti strādājošas virtuālās mašīnas ar 150 GB RAM atmiņas skaitītājiem.
Tālāk redzamajā diagrammā VM ir acīmredzamas problēmas. Zem diagrammas var redzēt, ka šai VM tika izmantotas visas aprakstītās metodes darbam ar RAM. Balons šai virtuālajai mašīnai ir daudz lielāks nekā Consumed. Patiesībā VM ir vairāk miris nekā dzīvs.
ESXTOP
Tāpat kā ar centrālo procesoru, ja mēs vēlamies ātri novērtēt situāciju resursdatorā, kā arī tā dinamiku ar intervālu līdz 2 sekundēm, mums vajadzētu izmantot ESXTOP.
ESXTOP atmiņas ekrāns tiek izsaukts ar taustiņu “m”, un tas izskatās šādi (atlasīti lauki B, D, H, J, K, L, O):
Mūs interesēs šādi parametri:
Mem overcommit vid — resursdatora atmiņas pārsūtīšanas vidējā vērtība 1, 5 un 15 minūtes. Ja tas ir virs nulles, tad tas ir iemesls paskatīties uz notiekošo, bet ne vienmēr ir problēmu rādītājs.
Rindās PMEM/MB и VMKMEM/MB — informācija par servera fizisko atmiņu un VMkernel pieejamo atmiņu. Starp interesantajām lietām šeit varat redzēt minfree vērtību (MB), resursdatora stāvokli atmiņā (mūsu gadījumā augstu).
Rindā NUMA/MB jūs varat redzēt RAM sadalījumu pa NUMA mezgliem (ligzdām). Šajā piemērā sadalījums ir nevienmērīgs, kas principā nav ļoti labs.
Tālāk ir sniegta vispārīga servera statistika par atmiņas atjaunošanas metodēm.
PSHARE/MB — tā ir TPS statistika;
SWAP/MB — Mijmaiņas darījumu izmantošanas statistika;
ZIP/MB — atmiņas lapu saspiešanas statistika;
MEMCTL/MB — Balona draivera lietošanas statistika.
Atsevišķām virtuālajām mašīnām mūs varētu interesēt tālāk norādītā informācija. VM vārdus slēpu, lai nemulsinātu publiku :). Ja ESXTOP metrika ir līdzīga vSphere skaitītājam, es nodrošināšu atbilstošo skaitītāju.
MEMSZ — VM konfigurētās atmiņas apjoms (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + neskarts.
GRANT — Piešķirts MB.
TCHD — Aktīvs MB.
MCTL? — vai virtuālajā mašīnā ir instalēts balona draiveris.
MCTLSZ — Balons uz MB.
MCTLGT — RAM apjoms (MB), ko ESXi vēlas noņemt no virtuālās mašīnas, izmantojot balona draiveri (Memctl Target).
MCTLMAX — maksimālais RAM apjoms (MB), ko ESXi var noņemt no virtuālās mašīnas, izmantojot balona draiveri.
SWCUR — pašreizējais RAM apjoms (MB), kas VM piešķirts no mijmaiņas faila.
S.W.G.T. — RAM apjoms (MB), ko ESXi vēlas piešķirt VM no mijmaiņas faila (Swap Target).
Varat arī skatīt detalizētāku informāciju par virtuālās mašīnas NUMA topoloģiju, izmantojot ESXTOP. Lai to izdarītu, atlasiet laukus D, G:
MAZS – NUMA mezgli, kuros atrodas virtuālā mašīna. Šeit uzreiz var pamanīt platus vm, kas neder vienā NUMA mezglā.
NRMEM – cik megabaitu atmiņas VM aizņem no attālā NUMA mezgla.
NLMEM – cik megabaitu atmiņas VM aizņem no vietējā NUMA mezgla.
N%L – VM atmiņas procentuālais daudzums lokālajā NUMA mezglā (ja tas ir mazāks par 80%, var rasties veiktspējas problēmas).
Atmiņa uz hipervizora
Ja CPU skaitītāji hipervizoram parasti neinteresē, tad ar atmiņu situācija ir pretēja. Liels atmiņas lietojums virtuālajā mašīnā ne vienmēr norāda uz veiktspējas problēmu, bet augsts atmiņas lietojums hipervizorā aktivizē atmiņas pārvaldības paņēmienus un rada problēmas ar VM veiktspēju. Jums ir jāuzrauga resursdatora atmiņas lietojuma trauksmes un jānovērš VM nokļūšana mijmaiņas programmā.
Atsaukt apmaiņu
Ja VM tiek noķerts Swap, tās veiktspēja ir ievērojami samazināta. Balonēšanas un saspiešanas pēdas ātri pazūd pēc brīvas RAM parādīšanās resursdatorā, taču virtuālā mašīna nesteidzas atgriezties no Swap servera RAM.
Pirms ESXi 6.0 vienīgais uzticamais un ātrs veids, kā noņemt virtuālo mašīnu no Swap, bija pārstartēšana (precīzāk, konteinera izslēgšana/ieslēgšana). Sākot ar ESXi 6.0, lai gan tas nav pilnīgi oficiāls, ir parādījies efektīvs un uzticams veids, kā noņemt virtuālo mašīnu no Swap. Vienā no konferencēm man bija iespēja runāt ar vienu no VMware inženieriem, kas ir atbildīgi par CPU plānotāju. Viņš apstiprināja, ka metode ir diezgan efektīva un droša. Mūsu pieredze liecina, ka arī ar to nebija nekādu problēmu.
Faktiskās komandas VM noņemšanai no Swap Dankans Epings. Es neatkārtošu detalizētu aprakstu, es sniegšu tikai tā izmantošanas piemēru. Kā redzat ekrānuzņēmumā, kādu laiku pēc norādītās komandas izpildes Swap uz VM pazūd.
Padomi RAM pārvaldībai ESXi
Visbeidzot, šeit ir daži padomi, kas palīdzēs izvairīties no problēmām ar VM veiktspēju RAM dēļ:
- Izvairieties no RAM pārmērīgas abonēšanas produktīvos klasteros. Vēlams, lai klasterī vienmēr būtu ~20-30% brīvas atmiņas, lai DRS (un administratoram) būtu kur manevrēt un VM migrācijas laikā neiet uz Swap. Tāpat neaizmirstiet par kļūdu pielaides robežu. Ir nepatīkami, ja, kad viens serveris neizdodas un virtuālā mašīna tiek atsāknēta, izmantojot HA, dažas mašīnas arī pāriet uz Swap.
- Ļoti konsolidētās infrastruktūrās Mēģiniet NEveidot virtuālās mašīnas, kuru atmiņa ir lielāka par pusi no resursdatora atmiņas. Tas atkal palīdzēs DRS bez problēmām izplatīt virtuālās mašīnas pa klasteru serveriem. Šis noteikums, protams, nav universāls :).
- Uzmanieties no resursdatora atmiņas izmantošanas trauksmes.
- Neaizmirstiet instalēt VMware rīkus virtuālajā mašīnā un neizslēdziet Ballooning.
- Apsveriet iespēju iespējot Inter-VM TPS un atspējot lielas lapas VDI un testa vidēs.
- Ja virtuālajā mašīnā rodas veiktspējas problēmas, pārbaudiet, vai tā izmanto atmiņu no attālā NUMA mezgla.
- Noņemiet virtuālās mašīnas no Swap, cik ātri vien iespējams! Cita starpā, ja virtuālā mašīna ir Swap, uzglabāšanas sistēma cieš acīmredzamu iemeslu dēļ.
Tas man ir viss par RAM. Zemāk ir saistīti raksti tiem, kas vēlas iedziļināties. Nākamais raksts būs veltīts storajam.
Noderīgas saites
Avots: www.habr.com
