{"id":35292,"date":"2019-10-31T22:03:28","date_gmt":"2019-10-31T19:03:28","guid":{"rendered":"https:\/\/prohoster.info\/blog\/analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory\/"},"modified":"2019-10-31T22:03:28","modified_gmt":"2019-10-31T19:03:28","slug":"analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory","title":{"rendered":"Analiza wydajno\u015bci VM w VMware vSphere. Cz\u0119\u015b\u0107 2: Pami\u0119\u0107","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Analiza
\n
\nCz\u0119\u015b\u0107 1. O CPU<\/a><\/noindex><\/p>\n

W tym artykule om\u00f3wimy liczniki wydajno\u015bci pami\u0119ci RAM w vSphere.
\nZ pami\u0119ci\u0105 wszystko wydaje si\u0119 by\u0107 bardziej jednoznaczne ni\u017c z procesorem: je\u015bli na VM pojawiaj\u0105 si\u0119 problemy z wydajno\u015bci\u0105, ci\u0119\u017cko ich nie zauwa\u017cy\u0107. Z kolei gdy si\u0119 pojawi\u0105, znacznie trudniej je rozwi\u0105za\u0107. Ale o wszystkim po kolei. <\/a><\/noindex><\/p>\n

Troch\u0119 teorii<\/h3>\n

\nPami\u0119\u0107 operacyjna maszyn wirtualnych pobierana jest z pami\u0119ci serwera, na kt\u00f3rym dzia\u0142aj\u0105 VM. Jest to ca\u0142kowicie oczywiste :). Je\u015bli pami\u0119ci operacyjnej serwera brakuje dla wszystkich ch\u0119tnych, ESXi zaczyna stosowa\u0107 techniki optymalizacji zu\u017cycia pami\u0119ci operacyjnej (techniki odzyskiwania pami\u0119ci). W przeciwnym razie systemy operacyjne VM kr crashowa\u0142yby z b\u0142\u0119dami dost\u0119pu do RAM. <\/p>\n

Jakie techniki zastosowa\u0107, decyduje ESXi, w zale\u017cno\u015bci od obci\u0105\u017cenia pami\u0119ci operacyjnej:<\/p>\n

Stan pami\u0119ci<\/b><\/p>\n

Granica<\/b><\/p>\n

Dzia\u0142ania<\/b><\/p>\n

Wysoki<\/p>\n

400% od minFree<\/p>\n

Po osi\u0105gni\u0119ciu g\u00f3rnej granicy, du\u017ce strony pami\u0119ci dzielone s\u0105 na mniejsze (TPS dzia\u0142a w standardowym trybie).<\/p>\n

Wyczy\u015b\u0107<\/p>\n

100% od minFree<\/p>\n

Du\u017ce strony pami\u0119ci dzielone s\u0105 na mniejsze, TPS dzia\u0142a wymuszone.<\/p>\n

Mi\u0119kki<\/p>\n

64% od minFree<\/p>\n

TPS + Balloon<\/p>\n

Twardy<\/p>\n

32% od minFree<\/p>\n

TPS + Kompresja + Swap<\/p>\n

Niski<\/p>\n

16% od minFree<\/p>\n

Kompresja + Swap + Blokada<\/p>\n

\u0179r\u00f3d\u0142o<\/a><\/noindex> <\/p>\n

minFree \u2014 to pami\u0119\u0107 operacyjna wymagana do dzia\u0142ania hypervisora. <\/p>\n

Do ESXi 4.1 w\u0142\u0105cznie minFree domy\u015blnie wynosi\u0142o 6% obj\u0119to\u015bci pami\u0119ci operacyjnej serwera (procent mo\u017cna by\u0142o zmieni\u0107 za pomoc\u0105 opcji Mem.MinFreePct na ESXi). W p\u00f3\u017aniejszych wersjach, z uwagi na wzrost obj\u0119to\u015bci pami\u0119ci w serwerach, minFree zacz\u0119to oblicza\u0107 w oparciu o ilo\u015b\u0107 pami\u0119ci hosta, a nie jako sta\u0142\u0105 warto\u015b\u0107 procentow\u0105. <\/p>\n

Warto\u015b\u0107 minFree (domy\u015blnie) oblicza si\u0119 w nast\u0119puj\u0105cy spos\u00f3b:<\/p>\n

Procent pami\u0119ci zarezerwowanej dla minFree<\/b><\/p>\n

Zakres pami\u0119ci<\/b><\/p>\n

6%<\/p>\n

0-4 GB<\/p>\n

4%<\/p>\n

4-12 GB<\/p>\n

2%<\/p>\n

12-28 GB<\/p>\n

1%<\/p>\n

Pozosta\u0142a pami\u0119\u0107<\/p>\n

\u0179r\u00f3d\u0142o<\/a><\/noindex><\/p>\n

Na przyk\u0142ad dla serwera z 128 GB RAM warto\u015b\u0107 MinFree b\u0119dzie nast\u0119puj\u0105ca:
\nMinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
\nFaktyczna warto\u015b\u0107 mo\u017ce si\u0119 r\u00f3\u017cni\u0107 o kilka setek MB, zale\u017cy to od serwera i pami\u0119ci operacyjnej.<\/p>\n

Procent pami\u0119ci zarezerwowanej dla minFree<\/b><\/p>\n

Zakres pami\u0119ci<\/b><\/p>\n

Warto\u015b\u0107 dla 128 GB<\/b><\/p>\n

6%<\/p>\n

0-4 GB<\/p>\n

245,76 MB<\/p>\n

4%<\/p>\n

4-12 GB<\/p>\n

327,68 MB<\/p>\n

2%<\/p>\n

12-28 GB<\/p>\n

327,68 MB<\/p>\n

1%<\/p>\n

Pozosta\u0142a pami\u0119\u0107 (100 GB)<\/p>\n

1024 MB<\/p>\n

\nZazwyczaj stan High mo\u017cna uzna\u0107 za normalny dla \u015brodowisk produkcyjnych. W przypadku \u015brodowisk testowych i deweloperskich akceptowalne mog\u0105 by\u0107 stany Clear\/Soft. Je\u015bli pami\u0119\u0107 RAM na ho\u015bcie spadnie poni\u017cej 64% MinFree, to w maszynach wirtualnych na nim dzia\u0142aj\u0105cych z pewno\u015bci\u0105 wyst\u0105pi\u0105 problemy z wydajno\u015bci\u0105.<\/p>\n

W ka\u017cdym stanie stosowane s\u0105 okre\u015blone techniki odzyskiwania pami\u0119ci, pocz\u0105wszy od TPS, kt\u00f3ry praktycznie nie wp\u0142ywa na wydajno\u015b\u0107 maszyn wirtualnych, a ko\u0144cz\u0105c na swapowaniu. Opisz\u0119 je szczeg\u00f3\u0142owo. <\/p>\n

Transparent Page Sharing (TPS).<\/b> TPS to w du\u017cym uproszczeniu deduplikacja stron pami\u0119ci RAM maszyn wirtualnych na serwerze.<\/p>\n

ESXi przeszukuje identyczne strony pami\u0119ci RAM maszyn wirtualnych, obliczaj\u0105c i por\u00f3wnuj\u0105c sum\u0119 kontroln\u0105 stron, i usuwa duplikaty stron, zast\u0119puj\u0105c je linkami do tej samej strony w fizycznej pami\u0119ci serwera. W rezultacie zu\u017cycie fizycznej pami\u0119ci maleje, co pozwala na pewn\u0105 nadsubskrypcj\u0119 pami\u0119ci praktycznie bez obni\u017cenia wydajno\u015bci.<\/p>\n

\"Analiza
\n\u0179r\u00f3d\u0142o<\/a><\/noindex><\/p>\n

Mechanizm ten dzia\u0142a tylko dla stron pami\u0119ci o rozmiarze 4 Kbyte (ma\u0142e strony). Hypervisor nawet nie pr\u00f3buje deduplikowa\u0107 stron o rozmiarze 2 Mbyte (du\u017ce strony): szansa na znalezienie identycznych stron o takim rozmiarze jest niewielka.<\/p>\n

Domy\u015blnie ESXi przydziela pami\u0119\u0107 du\u017cym stronom. Rozdzielanie du\u017cych stron na ma\u0142e zaczyna si\u0119 po osi\u0105gni\u0119ciu progu stanu High i odbywa si\u0119 przymusowo, gdy osi\u0105gany jest stan Clear (patrz tabela stan\u00f3w hypervisora).<\/p>\n

Je\u015bli jednak chcesz, aby TPS rozpocz\u0105\u0142 dzia\u0142anie, nie czekaj\u0105c na zape\u0142nienie pami\u0119ci RAM hosta, w zaawansowanych opcjach ESXi nale\u017cy ustawi\u0107 warto\u015b\u0107 \u201cMem.AllocGuestLargePage\u201d<\/i> na 0 (domy\u015blnie 1). Wtedy przydzielanie du\u017cych stron pami\u0119ci dla maszyn wirtualnych zostanie wy\u0142\u0105czone.<\/p>\n

Od grudnia 2014 w wszystkich wydaniach ESXi TPS mi\u0119dzy VM domy\u015blnie jest wy\u0142\u0105czony, poniewa\u017c znaleziono luk\u0119, kt\u00f3ra teoretycznie pozwala uzyska\u0107 dost\u0119p do pami\u0119ci RAM innej VM z jednej VM. Szczeg\u00f3\u0142y tutaj. Informacje o praktycznej realizacji wykorzystywania luki TPS nie by\u0142y mi znane.<\/p>\n

Polityka TPS jest kontrolowana za pomoc\u0105 zaawansowanej opcji \u201cMem.ShareForceSalting\u201d<\/i> na ESXi:
\n0 \u2014 Inter-VM TPS. TPS dzia\u0142a dla stron r\u00f3\u017cnych VM;
\n1 \u2013 TPS dla VM z identyczn\u0105 warto\u015bci\u0105 \u201csched.mem.pshare.salt\u201d w VMX;
\n2 (domy\u015blnie) \u2013 Intra-VM TPS. TPS dzia\u0142a dla stron wewn\u0105trz VM.<\/p>\n

Zdecydowanie warto wy\u0142\u0105cza\u0107 du\u017ce strony i w\u0142\u0105cza\u0107 Inter-VM TPS na \u015brodowiskach testowych. Mo\u017cna to r\u00f3wnie\u017c zastosowa\u0107 w \u015brodowiskach z du\u017c\u0105 liczb\u0105 jednorodnych VM. Na przyk\u0142ad, w \u015brodowiskach z VDI oszcz\u0119dno\u015b\u0107 fizycznej pami\u0119ci mo\u017ce si\u0119ga\u0107 dziesi\u0105tek procent. <\/p>\n

Balonowanie pami\u0119ci.<\/b> Balonowanie nie jest ju\u017c tak niewinn\u0105 i przezroczyst\u0105 technik\u0105 dla systemu operacyjnego VM jak TPS. Jednak przy odpowiednim zastosowaniu z balonowaniem mo\u017cna \u017cy\u0107 i nawet pracowa\u0107.<\/p>\n

Wraz z VMware Tools na VM instalowany jest specjalny sterownik, zwany Balloon Driver (to tak\u017ce vmmemctl). Gdy hipernadzorca zaczyna odczuwa\u0107 brak fizycznej pami\u0119ci i przechodzi w stan Soft, ESXi prosi VM o zwr\u00f3cenie nieu\u017cywanej pami\u0119ci RAM przez ten Balloon Driver. Sterownik z kolei dzia\u0142a na poziomie systemu operacyjnego i prosi o woln\u0105 pami\u0119\u0107. Hipernadzorca widzi, jakie strony pami\u0119ci fizycznej zajmuje Balloon Driver, zabiera pami\u0119\u0107 z wirtualnej maszyny i zwraca j\u0105 do hosta. Problemy z dzia\u0142aniem OS nie wyst\u0119puj\u0105, poniewa\u017c na poziomie OS pami\u0119\u0107 jest zaj\u0119ta przez Balloon Drivera. Domy\u015blnie Balloon Driver mo\u017ce zabra\u0107 do 65% pami\u0119ci VM.<\/p>\n

Je\u015bli na VM nie s\u0105 zainstalowane VMware Tools lub balonowanie jest wy\u0142\u0105czone (nie polecam, ale s\u0105) KB<\/a><\/noindex>:), hipernadzorca natychmiast przechodzi do bardziej rygorystycznych technik odejmowania pami\u0119ci. Wniosek: upewnij si\u0119, \u017ce na VM s\u0105 zainstalowane VMware Tools.<\/p>\n

\"Analiza
\nDzia\u0142anie Balloon Drivera mo\u017cna sprawdzi\u0107 z poziomu OS poprzez VMware Tools.<\/i>.<\/p>\n

Kompresja pami\u0119ci.<\/b> Ta technika jest stosowana, gdy ESXi osi\u0105ga stan Hard. Z nazwy wynika, \u017ce ESXi stara si\u0119 skompresowa\u0107 4 KB stron\u0119 pami\u0119ci RAM do 2 KB, a tym samym zwolni\u0107 nieco miejsca w fizycznej pami\u0119ci serwera. Technika ta znacznie zwi\u0119ksza czas dost\u0119pu do zawarto\u015bci stron pami\u0119ci RAM VM, poniewa\u017c stron\u0119 nale\u017cy najpierw rozpakowa\u0107. Czasami nie wszystkie strony udaje si\u0119 skompresowa\u0107, a sam proces zajmuje troch\u0119 czasu. Dlatego ta technika w praktyce nie jest zbyt efektywna.<\/p>\n

Zamiana pami\u0119ci.<\/b> Po kr\u00f3tkiej fazie kompresji pami\u0119ci ESXi praktycznie nieuchronnie (je\u015bli VM nie zosta\u0142y przeniesione na inne hosty lub nie zosta\u0142y wy\u0142\u0105czone) przechodzi do zamiany. A je\u015bli pami\u0119ci zostaje bardzo ma\u0142o (stan Low), hipernadzorca r\u00f3wnie\u017c przestaje przydziela\u0107 VM strony pami\u0119ci, co mo\u017ce powodowa\u0107 problemy w go\u015bcinnych systemach operacyjnych VM.<\/p>\n

Oto, jak dzia\u0142a Swapping. W momencie w\u0142\u0105czenia maszyny wirtualnej tworzony jest plik o rozszerzeniu .vswp. Jego rozmiar odpowiada niezarezerwowanej pami\u0119ci RAM VM: to r\u00f3\u017cnica mi\u0119dzy skonfigurowan\u0105 a zarezerwowan\u0105 pami\u0119ci\u0105. W trakcie dzia\u0142ania Swappingu ESXi zapisuje strony pami\u0119ci maszyny wirtualnej do tego pliku i zaczyna dzia\u0142a\u0107 na nim zamiast na fizycznej pami\u0119ci serwera. Oczywi\u015bcie, taka 'pami\u0119\u0107 operacyjna' jest kilkakrotnie wolniejsza od prawdziwej, nawet je\u015bli .vswp jest na szybkim no\u015bniku.<\/p>\n

W przeciwie\u0144stwie do Ballooningu, kiedy VM odbierane s\u0105 nieu\u017cywane strony, podczas Swappingu na dysk mog\u0105 przej\u015b\u0107 strony, kt\u00f3re s\u0105 aktywnie u\u017cywane przez system operacyjny lub aplikacje w VM. W rezultacie wydajno\u015b\u0107 VM spada a\u017c do zawieszenia. VM formalnie dzia\u0142a i przynajmniej mo\u017cna j\u0105 poprawnie wy\u0142\u0105czy\u0107 z OS. Je\u015bli zachowasz cierpliwo\u015b\u0107 \ud83d\ude09<\/p>\n

Je\u015bli VM przenie\u015bli si\u0119 do Swap, to sytuacja awaryjna, kt\u00f3rej lepiej unika\u0107, gdy to mo\u017cliwe.<\/p>\n

G\u0142\u00f3wne wska\u017aniki wydajno\u015bci pami\u0119ci maszyny wirtualnej<\/h3>\n

\nDotarli\u015bmy do sedna sprawy. Do monitorowania stanu pami\u0119ci w VM dost\u0119pne s\u0105 nast\u0119puj\u0105ce wska\u017aniki:<\/p>\n

Active<\/b> \u2014 pokazuje obj\u0119to\u015b\u0107 pami\u0119ci operacyjnej (KB), do kt\u00f3rej VM mia\u0142a dost\u0119p w poprzednim okresie pomiaru.<\/p>\n

Usage<\/b> \u2014 to samo, co Active, ale w procentach od skonfigurowanej pami\u0119ci operacyjnej VM. Oblicza si\u0119 to wed\u0142ug nast\u0119puj\u0105cego wzoru: active \u00f7 virtual machine configured memory size.
\nWysoki Usage i Active nie zawsze s\u0105 wska\u017anikiem problem\u00f3w z wydajno\u015bci\u0105 VM. Je\u015bli VM agresywnie wykorzystuje pami\u0119\u0107 (przynajmniej ma do niej dost\u0119p), nie oznacza to, \u017ce jej brakuje. Raczej jest to pow\u00f3d, by przyjrze\u0107 si\u0119, co dzieje si\u0119 w OS.
\nIstnieje standardowy Alarm dotycz\u0105cy Usage pami\u0119ci dla VM:<\/p>\n

\"Analiza
\n
\nWsp\u00f3lny<\/b> \u2014 obj\u0119to\u015b\u0107 pami\u0119ci operacyjnej VM, zduplikowanej za pomoc\u0105 TPS (wewn\u0105trz VM lub mi\u0119dzy VM).<\/p>\n

Granted<\/b> \u2014 obj\u0119to\u015b\u0107 fizycznej pami\u0119ci hosta (KB), kt\u00f3ra zosta\u0142a przydzielona VM. Zawiera Shared.<\/p>\n

Consumed<\/b> (Granted \u2014 Shared) \u2014 obj\u0119to\u015b\u0107 fizycznej pami\u0119ci (KB), kt\u00f3r\u0105 VM konsumuje z hosta. Nie zawiera Shared.<\/p>\n

Je\u015bli cz\u0119\u015b\u0107 pami\u0119ci VM nie pochodzi z fizycznej pami\u0119ci hosta, a z pliku wymiany lub pami\u0119\u0107 zosta\u0142a zabrana VM przez Balloon Driver, ta obj\u0119to\u015b\u0107 nie jest uwzgl\u0119dniana w Granted i Consumed.
\nWysokie warto\u015bci Granted i Consumed s\u0105 ca\u0142kowicie normalne. System operacyjny stopniowo odbiera pami\u0119\u0107 od hipernadzorcy i nie oddaje jej z powrotem. Z czasem u aktywnie dzia\u0142aj\u0105cej VM warto\u015bci tych licznik\u00f3w zbli\u017caj\u0105 si\u0119 do wielko\u015bci skonfigurowanej pami\u0119ci i tam pozostaj\u0105.<\/p>\n

Zero<\/b> \u2014 ilo\u015b\u0107 pami\u0119ci RAM VM (KB), kt\u00f3ra zawiera zera. Taka pami\u0119\u0107 jest uwa\u017cana przez hipernadzorc\u0119 za woln\u0105 i mo\u017ce by\u0107 przydzielona innym wirtualnym maszynom. Po tym, jak system operacyjny go\u015bcia zapisa\u0142 co\u015b w zera pami\u0119ci, przechodzi ona do kategorii Consumed i nie wraca ju\u017c z powrotem.<\/p>\n

Reserved Overhead<\/b> \u2014 ilo\u015b\u0107 pami\u0119ci RAM VM (KB) zarezerwowanej przez hipernadzorc\u0119 do pracy VM. To ma\u0142a ilo\u015b\u0107, ale musi by\u0107 obecna na ho\u015bcie, inaczej VM si\u0119 nie uruchomi.<\/p>\n

Balloon<\/b> \u2014 ilo\u015b\u0107 pami\u0119ci RAM (KB) wydzielonej z VM za pomoc\u0105 sterownika Balloon.<\/p>\n

Compressed<\/b> \u2014 ilo\u015b\u0107 pami\u0119ci RAM (KB), kt\u00f3r\u0105 uda\u0142o si\u0119 skompresowa\u0107.<\/p>\n

Swapped<\/b> \u2014 ilo\u015b\u0107 pami\u0119ci RAM (KB), kt\u00f3ra, w przypadku braku pami\u0119ci fizycznej na serwerze, zosta\u0142a przeniesiona na dysk.
\nBalloon oraz inne liczniki technik odzyskiwania pami\u0119ci s\u0105 r\u00f3wne zeru.<\/p>\n

Tak wygl\u0105da wykres z licznikami Memory dla normalnie dzia\u0142aj\u0105cej VM z 150 GB pami\u0119ci RAM.<\/p>\n

\"Analiza
\n
\nNa wykresie poni\u017cej widoczne s\u0105 wyra\u017ane problemy z VM. Pod wykresem wida\u0107, \u017ce dla tej VM zosta\u0142y wykorzystane wszystkie opisane techniki pracy z pami\u0119ci\u0105 RAM. Balloon dla tej VM jest znacznie wi\u0119kszy ni\u017c Consumed. W rzeczywisto\u015bci VM jest raczej martwa ni\u017c \u017cywa. <\/p>\n

\"Analiza
\n<\/p>\n

ESXTOP<\/h3>\n

\nJak w przypadku CPU, je\u015bli chcemy szybko oceni\u0107 sytuacj\u0119 na ho\u015bcie, a tak\u017ce jej dynamik\u0119 w interwa\u0142ach do 2 sekund, warto skorzysta\u0107 z ESXTOP.<\/p>\n

Ekran ESXTOP dotycz\u0105cy pami\u0119ci wywo\u0142uje si\u0119 klawiszem \u201em\u201d i wygl\u0105da nast\u0119puj\u0105co (wybrane pola B,D,H,J,K,L,O):<\/p>\n

\"Analiza
\n
\nInteresuj\u0105ce nas b\u0119d\u0105 nast\u0119puj\u0105ce parametry: <\/p>\n

Mem overcommit avg<\/b> \u2014 \u015brednia warto\u015b\u0107 przekroczenia pami\u0119ci na ho\u015bcie za 1, 5 i 15 minut. Je\u015bli jest wy\u017csza od zera, to jest to pow\u00f3d do przyjrzenia si\u0119, co si\u0119 dzieje, ale nie zawsze wskazuje na istnienie problem\u00f3w.<\/p>\n

W liniach PMEM\/MB<\/b> i VMKMEM\/MB<\/b> \u2014 informacje o fizycznej pami\u0119ci serwera i pami\u0119ci dost\u0119pnej dla VMkernel. Mo\u017cna tu zobaczy\u0107 warto\u015b\u0107 minfree (w MB), stan hosta pod wzgl\u0119dem pami\u0119ci (w naszym przypadku wysoki).<\/p>\n

W linii NUMA\/MB<\/b> mo\u017cna zobaczy\u0107 rozk\u0142ad pami\u0119ci RAM na w\u0119z\u0142ach NUMA (gniazda). W tym przyk\u0142adzie rozk\u0142ad jest nier\u00f3wnomierny, co og\u00f3lnie nie jest zbyt dobre.<\/p>\n

Poni\u017cej znajduje si\u0119 og\u00f3lna statystyka dotycz\u0105ca serwera pod wzgl\u0119dem technik odzyskiwania pami\u0119ci:<\/p>\n

PSHARE\/MB<\/b> \u2014 to statystyka TPS;<\/p>\n

SWAP\/MB<\/b> \u2014 statystyka u\u017cycia Swap;<\/p>\n

ZIP\/MB<\/b> \u2014 statystyka kompresji stron pami\u0119ci;<\/p>\n

MEMCTL\/MB<\/b> \u2014 statystyka u\u017cycia Balloon Driver.<\/p>\n

W przypadku poszczeg\u00f3lnych VM mo\u017cemy by\u0107 zainteresowani nast\u0119puj\u0105cymi informacjami. Ukry\u0142em nazwy VM, aby nie dezorientowa\u0107 publiczno\u015bci :). Je\u015bli metryka ESXTOP jest podobna do licznika w vSphere, podaj\u0119 odpowiedni licznik. <\/p>\n

MEMSZ<\/b> \u2014 rozmiar pami\u0119ci skonfigurowanej na VM (MB).
\nMEMSZ = GRANT + MCTLSZ + SWCUR + untouched.<\/p>\n

GRANT<\/b> \u2014 Grant w MB.<\/p>\n

TCHD<\/b> \u2014 Aktywna w MB.<\/p>\n

MCTL?<\/b> \u2014 czy Balloon Driver jest zainstalowany na VM.<\/p>\n

MCTLSZ<\/b> \u2014 Balloon w MB.<\/p>\n

MCTLGT<\/b> \u2014 ilo\u015b\u0107 pami\u0119ci RAM (MB), kt\u00f3r\u0105 ESXi chce odebra\u0107 z VM za pomoc\u0105 Balloon Driver (Memctl Target).<\/p>\n

MCTLMAX<\/b> \u2014 maksymalna ilo\u015b\u0107 pami\u0119ci RAM (MB), kt\u00f3r\u0105 ESXi mo\u017ce odebra\u0107 z VM za pomoc\u0105 Balloon Driver.<\/p>\n

SWCUR<\/b> \u2014 obecna ilo\u015b\u0107 pami\u0119ci RAM (MB), przydzielona VM z pliku Swap. <\/p>\n

SWGT<\/b> \u2014 ilo\u015b\u0107 pami\u0119ci RAM (MB), kt\u00f3r\u0105 ESXi chce przydzieli\u0107 VM z pliku Swap (Swap Target).<\/p>\n

Za pomoc\u0105 ESXTOP mo\u017cna r\u00f3wnie\u017c zobaczy\u0107 bardziej szczeg\u00f3\u0142owe informacje o topologii NUMA VM. W tym celu nale\u017cy wybra\u0107 pola D,G:<\/p>\n

\"Analiza
\n
\nNHN<\/b> \u2013 w\u0119z\u0142y NUMA, na kt\u00f3rych znajduje si\u0119 VM. Tutaj mo\u017cna od razu zauwa\u017cy\u0107 szerokie VM, kt\u00f3re nie mieszcz\u0105 si\u0119 na jednym w\u0119\u017ale NUMA.<\/p>\n

NRMEM<\/b> \u2013 ile megabajt\u00f3w pami\u0119ci VM pobiera z zdalnego w\u0119z\u0142a NUMA.<\/p>\n

NLMEM<\/b> \u2013 ile megabajt\u00f3w pami\u0119ci VM pobiera z lokalnego w\u0119z\u0142a NUMA.<\/p>\n

N%L<\/b> \u2013 procent pami\u0119ci VM na lokalnym w\u0119\u017ale NUMA (je\u015bli mniej ni\u017c 80% \u2014 mog\u0105 wyst\u0105pi\u0107 problemy z wydajno\u015bci\u0105).<\/p>\n

Pami\u0119\u0107 na hypervisorze<\/h3>\n

\nJe\u015bli liczniki CPU na hypervisorze zazwyczaj nie budz\u0105 specjalnego zainteresowania, to sytuacja z pami\u0119ci\u0105 jest inna. Wysokie u\u017cycie pami\u0119ci na VM nie zawsze oznacza problem z wydajno\u015bci\u0105, ale wysokie u\u017cycie pami\u0119ci na hypervisorze uruchamia techniki zarz\u0105dzania pami\u0119ci\u0105 i mo\u017ce powodowa\u0107 problemy z wydajno\u015bci\u0105 VM. Nale\u017cy monitorowa\u0107 alarmy dotycz\u0105ce u\u017cycia pami\u0119ci hosta i zapobiega\u0107 przenoszeniu VM do Swap.<\/p>\n

\"Analiza
\n
\n\"Analiza
\n<\/p>\n

Unswap<\/h3>\n

\nJe\u015bli VM trafi\u0142 do Swap, jego wydajno\u015b\u0107 znacznie spada. \u015alady Ballooningu i kompresji szybko znikaj\u0105 po uwolnieniu pami\u0119ci RAM na ho\u015bcie, jednak powr\u00f3t z Swap do pami\u0119ci RAM serwera nie jest zbyt szybki dla wirtualnej maszyny.
\nDo wersji ESXi 6.0 jedynym pewnym i szybkim sposobem na wyprowadzenie VM z Swap by\u0142 restart (dok\u0142adniej, wy\u0142\u0105czenie\/w\u0142\u0105czenie kontenera). Zaczynaj\u0105c od ESXi 6.0, pojawi\u0142 si\u0119 chocia\u017c nie do ko\u0144ca oficjalny, ale dzia\u0142aj\u0105cy i niezawodny spos\u00f3b wyprowadzenia VM z Swap. Na jednej z konferencji mia\u0142em okazj\u0119 porozmawia\u0107 z jednym z in\u017cynier\u00f3w VMware, kt\u00f3ry odpowiada za planowanie CPU. Potwierdzi\u0142, \u017ce metoda jest w pe\u0142ni funkcjonalna i bezpieczna. W naszym do\u015bwiadczeniu nie zauwa\u017cono \u017cadnych problem\u00f3w z jej zastosowaniem.<\/p>\n

Rzeczywi\u015bcie polecenia do wyprowadzenia VM z Swap opisa\u0142<\/a><\/noindex> Duncan Epping. Nie b\u0119d\u0119 powtarza\u0107 szczeg\u00f3\u0142owego opisu, po prostu podam przyk\u0142ad jej zastosowania. Jak wida\u0107 na zrzucie ekranu, po pewnym czasie od wykonania podanego polecenia Swap na VM znika.<\/p>\n

\"Analiza
\n<\/p>\n

Porady dotycz\u0105ce zarz\u0105dzania pami\u0119ci\u0105 operacyjn\u0105 w ESXi<\/h3>\n

\nNa koniec zamieszczam kilka wskaz\u00f3wek, kt\u00f3re pomog\u0105 unikn\u0105\u0107 problem\u00f3w z wydajno\u015bci\u0105 VM z powodu pami\u0119ci operacyjnej:<\/p>\n