Sa artikulong ito, pag-uusapan natin ang tungkol sa mga performance counter ng random access memory (RAM) sa vSphere.
Tila na sa memorya ang lahat ay mas malinaw kaysa sa processor: kung ang isang VM ay may mga problema sa pagganap, mahirap na hindi mapansin ang mga ito. Ngunit kung lumitaw ang mga ito, mas mahirap na harapin ang mga ito. Ngunit una sa lahat.
Isang kaunting teorya
Ang RAM ng mga virtual machine ay kinuha mula sa memorya ng server kung saan tumatakbo ang mga VM. Halatang halata :). Kung ang RAM ng server ay hindi sapat para sa lahat, ang ESXi ay magsisimulang gumamit ng mga diskarte sa pagbawi ng memorya upang ma-optimize ang pagkonsumo ng RAM. Kung hindi, mag-crash ang mga operating system ng VM sa mga error sa pag-access ng RAM.
Aling mga diskarte na gagamitin ang ESXi ang magpapasya depende sa pagkarga ng RAM:
Katayuan ng memorya
hangganan
Aktibidad
Mataas
400% ng minLibre
Matapos maabot ang pinakamataas na limitasyon, ang malalaking memory page ay nahahati sa maliliit (gumagana ang TPS sa karaniwang mode).
malinaw
100% ng minLibre
Ang mga malalaking pahina ng memorya ay nasira sa maliliit, ang TPS ay pinipilit na gumana.
Malambot
64% ng minLibre
TPS + Lobo
Mahirap
32% ng minLibre
TPS + Compress + Swap
Mababa
16% ng minLibre
Compress + Swap + Block
Ang minFree ay ang RAM na kinakailangan para gumana ang hypervisor.
Bago kasama ang ESXi 4.1, inayos ang minFree bilang default - 6% ng RAM ng server (maaaring baguhin ang porsyento sa pamamagitan ng opsyong Mem.MinFreePct sa ESXi). Sa mga susunod na bersyon, dahil sa pagtaas ng mga laki ng memorya sa mga server, nagsimulang kalkulahin ang minFree batay sa dami ng memorya ng host, at hindi bilang isang nakapirming porsyento.
Ang minFree (default) na halaga ay kinakalkula tulad ng sumusunod:
Porsiyento ng memorya na nakalaan para sa minFree
Saklaw ng memorya
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Natitirang alaala
Halimbawa, para sa isang server na may 128 GB ng RAM, ang halaga ng MinFree ay:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12MB = 1,88GB
Ang aktwal na halaga ay maaaring mag-iba ng ilang daang MB, depende ito sa server at RAM.
Porsiyento ng memorya na nakalaan para sa minFree
Saklaw ng memorya
Halaga para sa 128 GB
6%
0-4 GB
245,76 MB
4%
4-12 GB
327,68 MB
2%
12-28 GB
327,68 MB
1%
Natitirang memorya (100 GB)
1024 MB
Karaniwan, para sa mga produktibong paninindigan, ang High state lamang ang maaaring ituring na normal. Para sa mga pagsubok at development bench, ang Clear/Soft states ay maaaring katanggap-tanggap. Kung ang RAM sa host ay mas mababa sa 64% MinFree, ang mga VM na tumatakbo dito ay tiyak na may mga problema sa pagganap.
Sa bawat estado, ang ilang mga diskarte sa reclamation ng memorya ay inilalapat, simula sa TPS, na halos hindi nakakaapekto sa pagganap ng VM, at nagtatapos sa Swapping. Sasabihin ko sa iyo ang higit pa tungkol sa kanila.
Transparent na Pagbabahagi ng Pahina (TPS). Ang TPS ay, halos nagsasalita, deduplikasyon ng mga pahina ng memorya ng virtual machine sa isang server.
Ang ESXi ay naghahanap ng magkaparehong mga pahina ng virtual machine RAM sa pamamagitan ng pagbibilang at paghahambing ng hash sum ng mga pahina, at inaalis ang mga duplicate na pahina, na pinapalitan ang mga ito ng mga link sa parehong pahina sa pisikal na memorya ng server. Bilang resulta, nababawasan ang pagkonsumo ng pisikal na memorya at ang ilang oversubscription ng memorya ay maaaring makamit nang kaunti o walang pagkasira ng pagganap.
Gumagana lamang ang mekanismong ito para sa 4 na KB na memory page (maliit na pahina). Hindi man lang sinusubukan ng hypervisor na i-dedupe ang mga pahina na 2 MB (malalaking pahina): hindi maganda ang pagkakataong makahanap ng magkatulad na mga pahina.
Bilang default, ang ESXi ay naglalaan ng memorya sa malalaking pahina. Ang paghahati-hati ng malalaking pahina sa maliliit na pahina ay magsisimula kapag naabot na ang High state threshold at pinipilit kapag naabot ang Clear state (tingnan ang hypervisor state table).
Kung gusto mong magsimulang magtrabaho ang TPS nang hindi naghihintay na mapuno ang host RAM, sa Advanced Options ESXi kailangan mong itakda ang halaga “Mem.AllocGuestLargePage” sa 0 (default 1). Pagkatapos ay idi-disable ang paglalaan ng malalaking memory page para sa mga virtual machine.
Mula noong Disyembre 2014, sa lahat ng release ng ESXi, ang TPS sa pagitan ng mga VM ay hindi pinagana bilang default, dahil may nakitang kahinaan na ayon sa teorya ay nagbibigay-daan sa pag-access mula sa isang VM patungo sa RAM ng isa pang VM. Mga detalye dito. Wala akong nakitang impormasyon tungkol sa praktikal na pagpapatupad ng pagsasamantala sa kahinaan ng TPS.
Ang patakaran ng TPS ay kinokontrol sa pamamagitan ng advanced na opsyon “Mem.ShareForceSalting” sa ESXi:
0 - Inter-VM TPS. Gumagana ang TPS para sa mga pahina ng iba't ibang VM;
1 – TPS para sa VM na may parehong halaga ng “sched.mem.pshare.salt” sa VMX;
2 (default) - Intra-VM TPS. Gumagana ang TPS para sa mga pahina sa loob ng VM.
Tiyak na makatuwirang i-off ang malalaking page at i-on ang Inter-VM TPS sa mga test bench. Maaari rin itong gamitin para sa mga stand na may malaking bilang ng parehong uri ng VM. Halimbawa, sa mga stand na may VDI, ang mga matitipid sa pisikal na memorya ay maaaring umabot sa sampu-sampung porsyento.
memory ballooning. Ang ballooning ay hindi na isang hindi nakakapinsala at transparent na pamamaraan para sa VM operating system bilang TPS. Ngunit sa wastong aplikasyon, maaari kang mabuhay at magtrabaho sa Ballooning.
Kasama ng Vmware Tools, ang isang espesyal na driver na tinatawag na Balloon Driver (aka vmmemctl) ay naka-install sa VM. Kapag ang hypervisor ay nagsimulang maubusan ng pisikal na memorya at pumasok sa Soft state, hinihiling ng ESXi sa VM na i-reclaim ang hindi nagamit na RAM sa pamamagitan ng Balloon Driver na ito. Ang driver, sa turn, ay gumagana sa antas ng operating system at humihiling ng libreng memorya mula dito. Nakikita ng hypervisor kung aling mga pahina ng pisikal na memorya ang sinakop ng Balloon Driver, kinuha ang memorya mula sa virtual machine at ibinalik ito sa host. Walang mga problema sa pagpapatakbo ng OS, dahil sa antas ng OS ang memorya ay inookupahan ng Balloon Driver. Bilang default, ang Balloon Driver ay maaaring tumagal ng hanggang 65% ng memorya ng VM.
Kung ang VMware Tools ay hindi naka-install sa VM o ang Ballooning ay hindi pinagana (hindi ko inirerekomenda, ngunit mayroong :), agad na lumipat ang hypervisor sa mas mahigpit na mga diskarte sa pag-alis ng memorya. Konklusyon: siguraduhin na ang VMware Tools ay nasa VM.
Maaaring suriin ang operasyon ng Balloon Driver mula sa OS sa pamamagitan ng VMware Tools.
memory compression. Ginagamit ang diskarteng ito kapag naabot ng ESXi ang Hard state. Gaya ng ipinahihiwatig ng pangalan, sinusubukan ng ESXi na paliitin ang isang 4KB na pahina ng RAM sa 2KB at sa gayon ay magbakante ng ilang espasyo sa pisikal na memorya ng server. Ang diskarteng ito ay makabuluhang pinapataas ang oras ng pag-access sa mga nilalaman ng mga pahina ng VM RAM, dahil ang pahina ay dapat munang hindi ma-compress. Minsan hindi lahat ng page ay maaaring i-compress at ang proseso mismo ay tumatagal ng ilang oras. Samakatuwid, ang pamamaraan na ito ay hindi masyadong epektibo sa pagsasanay.
pagpapalit ng memorya. Pagkatapos ng isang maikling bahagi ng Memory Compression, halos hindi maiiwasan ang ESXi (kung ang mga VM ay hindi umalis para sa ibang mga host o naka-off) ay lilipat sa Swapping. At kung may napakakaunting memorya na natitira (Mababang estado), ang hypervisor ay hihinto din sa paglalaan ng mga pahina ng memorya sa VM, na maaaring magdulot ng mga problema sa guest OS ng VM.
Narito kung paano gumagana ang Swapping. Kapag na-on mo ang isang virtual machine, isang file na may extension na .vswp ay nilikha para dito. Katumbas ito ng laki sa walang reserbang RAM ng VM: ito ang pagkakaiba sa pagitan ng naka-configure at nakalaan na memorya. Kapag tumatakbo ang Swapping, inaalis ng ESXi ang mga pahina ng memorya ng virtual machine sa file na ito at magsisimulang magtrabaho kasama nito sa halip na ang pisikal na memorya ng server. Siyempre, ang naturang "operative" na memorya ay ilang mga order ng magnitude na mas mabagal kaysa sa tunay, kahit na ang .vswp ay nasa mabilis na storage.
Hindi tulad ng Ballooning, kapag ang mga hindi nagamit na page ay kinuha mula sa VM, na may Swapping, ang mga page na aktibong ginagamit ng OS o mga application sa loob ng VM ay maaaring lumipat sa disk. Bilang resulta, ang pagganap ng VM ay bumababa hanggang sa punto ng pagyeyelo. Ang VM ay pormal na gumagana at hindi bababa sa maaari itong maayos na hindi paganahin mula sa OS. Kung matiyaga ka 😉
Kung ang mga VM ay napunta sa Swap, ito ay isang abnormal na sitwasyon, na pinakamahusay na iwasan kung maaari.
Pangunahing VM memory performance counter
Kaya nakarating kami sa pangunahing punto. Upang subaybayan ang estado ng memorya sa VM, mayroong mga sumusunod na counter:
Aktibo — ipinapakita ang dami ng RAM (KB) na na-access ng VM sa nakaraang panahon ng pagsukat.
Paggamit - kapareho ng Aktibo, ngunit bilang isang porsyento ng na-configure na RAM ng VM. Kinakalkula gamit ang sumusunod na formula: aktibo ÷ virtual machine na naka-configure na laki ng memorya.
Ang Mataas na Paggamit at Aktibo, ayon sa pagkakabanggit, ay hindi palaging isang tagapagpahiwatig ng mga problema sa pagganap ng VM. Kung ang VM ay agresibong gumagamit ng memorya (hindi bababa sa nakakakuha ng access dito), hindi ito nangangahulugan na walang sapat na memorya. Sa halip, ito ay isang okasyon upang makita kung ano ang nangyayari sa OS.
Mayroong karaniwang Memory Usage Alarm para sa mga VM:
Ibinahagi - ang halaga ng VM RAM na na-deduplicate gamit ang TPS (sa loob ng VM o sa pagitan ng mga VM).
Ipinagkaloob - ang dami ng pisikal na memorya ng host (KB) na ibinigay sa VM. Kasama ang Shared.
Ginamit (Granted - Shared) - ang dami ng pisikal na memorya (KB) na kinokonsumo ng VM mula sa host. Hindi kasama ang Shared.
Kung ang bahagi ng memorya ng VM ay ibinigay hindi mula sa pisikal na memorya ng host, ngunit mula sa swap file, o ang memorya ay kinuha mula sa VM sa pamamagitan ng Balloon Driver, ang halagang ito ay hindi isinasaalang-alang sa Granted and Consumed.
Ang mga High Granted at Consumed na halaga ay ganap na normal. Ang operating system ay unti-unting kumukuha ng memorya mula sa hypervisor at hindi ito ibabalik. Sa paglipas ng panahon, sa isang aktibong tumatakbong VM, ang mga halaga ng mga counter na ito ay lumalapit sa dami ng naka-configure na memorya, at nananatili doon.
Wala — ang halaga ng VM RAM (KB), na naglalaman ng mga zero. Ang nasabing memorya ay itinuturing na libre ng hypervisor at maaaring ibigay sa iba pang mga virtual machine. Matapos maisulat ng guest OS ang isang bagay sa zeroed memory, mapupunta ito sa Consumed at hindi na bumalik.
Nakareserba sa Overhead — ang halaga ng VM RAM, (KB) na nakalaan ng hypervisor para sa operasyon ng VM. Ito ay isang maliit na halaga, ngunit ito ay dapat na magagamit sa host, kung hindi, ang VM ay hindi magsisimula.
Lobo — ang halaga ng RAM (KB) na nakuha mula sa VM gamit ang Balloon Driver.
Compressed - ang dami ng RAM (KB) na na-compress.
Ipinagpalit - ang halaga ng RAM (KB) na, dahil sa kakulangan ng pisikal na memorya sa server, inilipat sa disk.
Ang mga counter ng balloon at iba pang memory reclamation techniques ay zero.
Ganito ang hitsura ng graph na may mga Memory counter para sa isang normal na gumaganang VM na may 150 GB ng RAM.
Sa graph sa ibaba, ang VM ay may malinaw na mga problema. Sa ilalim ng graph, makikita mo na para sa VM na ito, ginamit ang lahat ng inilarawang pamamaraan para sa pagtatrabaho sa RAM. Ang lobo para sa VM na ito ay mas malaki kaysa sa Consumed. Sa katunayan, ang VM ay mas patay kaysa buhay.
ESXTOP
Tulad ng sa CPU, kung gusto nating mabilis na masuri ang sitwasyon sa host, pati na rin ang dynamics nito na may pagitan ng hanggang 2 segundo, dapat nating gamitin ang ESXTOP.
Ang screen ng ESXTOP sa pamamagitan ng Memory ay tinawag gamit ang "m" key at ganito ang hitsura (mga patlang B, D, H, J, K, L, O ay pinili):
Ang mga sumusunod na parameter ay magiging interesado sa amin:
Mem overcommit avg - ang average na halaga ng memory oversubscription sa host para sa 1, 5 at 15 minuto. Kung ito ay higit sa zero, kung gayon ito ay isang okasyon upang makita kung ano ang nangyayari, ngunit hindi palaging isang tagapagpahiwatig ng mga problema.
Sa mga linya PMEM/MB и VMKMEM/MB - impormasyon tungkol sa pisikal na memorya ng server at ang memorya na magagamit sa VMkernel. Mula sa kawili-wiling dito maaari mong makita ang halaga ng minfree (sa MB), ang estado ng host sa memorya (sa aming kaso, mataas).
Nasa linya NUMA/MB maaari mong makita ang pamamahagi ng RAM sa pamamagitan ng NUMA node (sockets). Sa halimbawang ito, ang pamamahagi ay hindi pantay, na, sa prinsipyo, ay hindi napakahusay.
Ang sumusunod ay pangkalahatang istatistika ng server sa mga diskarte sa pagbawi ng memorya:
PSHARE/MB ay mga istatistika ng TPS;
SWAP/MB — Pagpalitin ang mga istatistika ng paggamit;
ZIP/MB — mga istatistika ng compression ng pahina ng memorya;
MEMCTL/MB — Mga istatistika ng paggamit ng Balloon Driver.
Para sa mga indibidwal na VM, maaaring interesado kami sa sumusunod na impormasyon. Tinago ko ang mga VM names para hindi malito ang audience :). Kung ang sukatan ng ESXTOP ay katulad ng counter sa vSphere, ibibigay ko ang kaukulang counter.
MEMSZ — ang dami ng memorya na na-configure sa VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + hindi nagalaw.
Grant — Ibinigay sa MB.
TCHD — Aktibo sa MB.
MCTL? - kung naka-install ang Balloon Driver sa VM.
MCTLSZ — Lobo hanggang MB.
MCTLGT — ang halaga ng RAM (MB) na gustong kunin ng ESXi mula sa VM sa pamamagitan ng Balloon Driver (Memctl Target).
MCTLMAX - ang maximum na halaga ng RAM (MB) na maaaring kunin ng ESXi mula sa VM sa pamamagitan ng Balloon Driver.
SWCUR — ang kasalukuyang halaga ng RAM (MB) na inilalaan sa VM mula sa Swap file.
S.W.G.T. - ang halaga ng RAM (MB) na gustong ibigay ng ESXi sa VM mula sa Swap file (Swap Target).
Gayundin, sa pamamagitan ng ESXTOP, makakakita ka ng mas detalyadong impormasyon tungkol sa NUMA topology ng VM. Upang gawin ito, piliin ang mga patlang D, G:
MALIIT – NUMA node kung saan matatagpuan ang VM. Dito maaari mong agad na mapansin ang malawak na vm, na hindi magkasya sa isang NUMA node.
NRMEM - kung gaano karaming megabytes ng memory ang kinukuha ng VM mula sa malayong NUMA node.
NLMEM - kung gaano karaming megabytes ng memorya ang kinukuha ng VM mula sa lokal na NUMA node.
N%L – porsyento ng memorya ng VM sa lokal na NUMA node (kung mas mababa sa 80%, maaaring mangyari ang mga problema sa pagganap).
Memorya sa hypervisor
Kung ang mga counter ng CPU para sa hypervisor ay karaniwang hindi partikular na interes, kung gayon ang sitwasyon ay mababaligtad sa memorya. Ang Mataas na Paggamit ng Memory sa isang VM ay hindi palaging nagpapahiwatig ng isang problema sa pagganap, ngunit ang mataas na Paggamit ng Memory sa isang hypervisor ay nagti-trigger ng mga diskarte sa pamamahala ng memorya at nagiging sanhi ng mga problema sa pagganap sa VM. Dapat na subaybayan ang mga alarma sa Paggamit ng Memory ng Host upang maiwasan ang pagpasok ng VM sa Swap.
unswap
Kung ang isang VM ay nasa Swap, ang pagganap nito ay lubhang nababawasan. Ang mga bakas ng Ballooning at compression ay mabilis na nawawala pagkatapos lumitaw ang libreng RAM sa host, ngunit ang virtual machine ay hindi nagmamadaling bumalik mula sa Swap patungo sa server ng RAM.
Bago ang ESXi 6.0, ang tanging maaasahan at mabilis na paraan para makakuha ng VM sa Swap ay ang pag-reboot (para maging mas tumpak, i-off/i-on ang container). Simula sa ESXi 6.0, bagama't hindi masyadong opisyal, isang gumagana at maaasahang paraan upang alisin ang isang VM mula sa Swap ay lumitaw. Sa isa sa mga kumperensya, nakausap ko ang isa sa mga inhinyero ng VMware na namamahala sa CPU Scheduler. Kinumpirma niya na ang pamamaraan ay medyo gumagana at ligtas. Sa aming karanasan, wala ring problema dito.
Ang aktwal na mga utos para sa pag-alis ng VM mula sa Swap Duncan Epping. Hindi ko uulitin ang isang detalyadong paglalarawan, magbigay lamang ng isang halimbawa ng paggamit nito. Tulad ng makikita mo sa screenshot, ilang oras pagkatapos ng pagpapatupad ng mga tinukoy na command, mawawala ang Swap sa VM.
Mga Tip sa Pamamahala ng Memorya ng ESXi
Panghuli, narito ang ilang tip na makakatulong sa iyong maiwasan ang mga problema sa performance ng VM dahil sa RAM:
- Iwasan ang memory oversubscription sa mga productive cluster. Ito ay kanais-nais na laging magkaroon ng ~20-30% libreng memorya sa cluster upang ang DRS (at ang administrator) ay magkaroon ng puwang upang maniobra, at ang mga VM ay hindi napupunta sa Swap sa panahon ng paglipat. Gayundin, huwag kalimutan ang tungkol sa margin para sa fault tolerance. Hindi kanais-nais kapag, kapag nabigo ang isang server at na-reboot ang VM gamit ang HA, ang ilan sa mga makina ay napupunta din sa Swap.
- Sa lubos na pinagsama-samang mga imprastraktura, subukang HINDI gumawa ng mga VM na may higit sa kalahati ng memorya ng host. Muli itong makakatulong sa DRS na ipamahagi ang mga virtual machine sa mga cluster server nang walang anumang problema. Ang panuntunang ito, siyempre, ay hindi pangkalahatan :).
- Panoorin ang Host Memory Usage Alarm.
- Huwag kalimutang i-install ang VMware Tools sa VM at huwag i-off ang Ballooning.
- Pag-isipang i-enable ang Inter-VM TPS at i-disable ang Large Pages sa VDI at mga pansubok na kapaligiran.
- Kung ang VM ay nakakaranas ng mga isyu sa pagganap, tingnan kung ito ay gumagamit ng memorya mula sa isang malayuang NUMA node.
- Alisin ang iyong VM sa Swap sa lalong madaling panahon! Sa iba pang mga bagay, kung ang VM ay nasa Swap, para sa malinaw na mga kadahilanan, ang sistema ng imbakan ay naghihirap.
Iyon lang ang para sa akin tungkol sa RAM. Nasa ibaba ang isang kaugnay na artikulo para sa mga nais maghukay sa mga detalye. Ang susunod na artikulo ay nakatuon sa storadzh.
Kapaki-pakinabang na mga link
Pinagmulan: www.habr.com