Анализа на перформансите на VM во VMware vSphere. Дел 2: Меморија

Дел 1. За процесорот

Во оваа статија, ќе зборуваме за бројачите на перформанси на меморијата за случаен пристап (RAM) во vSphere.
Се чини дека со меморијата сè е појасно отколку со процесорот: ако VM има проблеми со перформансите, тешко е да не ги забележите. Но, ако се појават, многу потешко е да се справите со нив. Но, прво прво.

Малку теорија

RAM меморијата на виртуелните машини се зема од меморијата на серверот на кој работат VM-овите. Тоа е сосема очигледно :). Ако RAM меморијата на серверот не е доволна за секого, ESXi започнува да користи техники за рекултивација на меморијата за да ја оптимизира потрошувачката на RAM меморија. Во спротивно, VM оперативните системи би паднале со грешки при пристап до RAM меморијата.

Кои техники да се користат ESXi одлучува во зависност од оптоварувањето на RAM меморијата:

Статус на меморија

граница

Активност

Високо

400% од мин Бесплатно

По достигнувањето на горната граница, големите мемориски страници се делат на мали (TPS работи во стандарден режим).

Отстрани

100% од мин Бесплатно

Големите мемориски страници се скршени на мали, TPS е принуден да работи.

Мека

64% од мин Бесплатно

TPS + Балон

Тешко

32% од мин Бесплатно

TPS + Компресија + Размена

Ниско

16% од мин Бесплатно

Компресирај + Замени + Блокирај

Извор

minFree е RAM меморијата потребна за хипервизорот да работи.

Пред ESXi 4.1 инклузивно, minFree беше стандардно фиксиран - 6% од RAM меморијата на серверот (процентот може да се промени преку опцијата Mem.MinFreePct на ESXi). Во подоцнежните верзии, поради зголемувањето на големината на меморијата на серверите, minFree почна да се пресметува врз основа на количината на меморијата на домаќинот, а не како фиксен процент.

Вредноста minFree (стандардно) се пресметува на следниов начин:

Процент на меморија резервиран за minFree

Опсег на меморија

6%

0-4 GB

4%

4-12 GB

2%

12-28 GB

1%

Преостаната меморија

Извор

На пример, за сервер со 128 GB RAM, вредноста MinFree би била:
МинБесплатно = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
Вистинската вредност може да се разликува за неколку стотици MB, зависи од серверот и RAM меморијата.

Процент на меморија резервиран за minFree

Опсег на меморија

Вредност за 128 GB

6%

0-4 GB

245,76 MB

4%

4-12 GB

327,68 MB

2%

12-28 GB

327,68 MB

1%

Преостаната меморија (100 GB)

1024 MB

Обично, за продуктивни штандови, само Високата состојба може да се смета за нормална. За клупи за тестирање и развој, јасни/меки состојби може да бидат прифатливи. Ако RAM меморијата на домаќинот е помала од 64% MinFree, тогаш VM-ите што работат на него дефинитивно имаат проблеми со перформансите.

Во секоја состојба, се применуваат одредени техники за мелиорација на меморијата, почнувајќи од TPS, што практично не влијае на перформансите на VM и завршувајќи со Swapping. Ќе ви кажам повеќе за нив.

Транспарентно споделување на страници (TPS). TPS е, грубо кажано, дедупликација на мемориските страници на виртуелната машина на серверот.

ESXi бара идентични страници на RAM меморијата на виртуелната машина со броење и споредување на хаш-збирот на страниците и ги отстранува дупликатите страници, заменувајќи ги со врски до истата страница во физичката меморија на серверот. Како резултат на тоа, потрошувачката на физичка меморија е намалена и може да се постигне одредена претплата на меморијата со мало или без намалување на перформансите.

Извор

Овој механизам работи само за страници со меморија од 4 KB (мали страници). Хипервизорот не се ни обидува да дедупира страници од 2 MB (големи страници): шансата да се најдат идентични страници со оваа големина не е голема.

Стандардно, ESXi доделува меморија на големи страници. Преградувањето на големите страници на мали страници започнува кога ќе се достигне прагот на високата состојба и е принуден кога ќе се достигне состојбата Clear (видете ја табелата со состојби на хипервизор).

Ако сакате TPS да почне да работи без да чекате да се наполни RAM-от на домаќинот, во Advanced Options ESXi треба да ја поставите вредноста „Mem.AllocGuestLargePage“ до 0 (стандардно 1). Тогаш ќе се оневозможи распределбата на големи мемориски страници за виртуелни машини.

Од декември 2014 година, во сите изданија на ESXi, TPS помеѓу VM е стандардно оневозможено, бидејќи беше откриена ранливост што теоретски дозволува пристап од еден VM до RAM меморијата на друг VM. Детали овде. Не наидов на информации за практичното спроведување на искористување на ранливоста на TPS.

Политиката TPS контролирана преку напредна опција „Mem.ShareForceSalting“ на ESXi:
0 - Интер-ВМ ТПС. TPS работи за страници на различни VMs;
1 – TPS за VM со иста вредност „sched.mem.pshare.salt“ во VMX;
2 (стандардно) - Intra-VM TPS. TPS работи за страници внатре во VM.

Дефинитивно има смисла да се исклучат големите страници и да се вклучи Inter-VM TPS на тест клупи. Може да се користи и за штандови со голем број на ист тип на VM. На пример, на штандови со VDI, заштедите во физичката меморија може да достигнат десетици проценти.

мемориски балон. Балонирањето повеќе не е толку безопасна и транспарентна техника за VM оперативниот систем како TPS. Но, со соодветна примена, можете да живеете, па дури и да работите со Balooning.

Заедно со Vmware Tools, специјален драјвер наречен Balloon Driver (ака vmmemctl) е инсталиран на VM. Кога хипервизорот ќе почне да снема физичка меморија и ќе влезе во мека состојба, ESXi бара од VM да ја врати неискористената RAM меморија преку овој двигател на балон. Возачот, пак, работи на ниво на оперативен систем и бара слободна меморија од него. Хипервизорот гледа кои страници од физичката меморија ги окупирал Возачот на балон, ја зема меморијата од виртуелната машина и ја враќа на домаќинот. Нема проблеми со работата на ОС, бидејќи на ниво на ОС меморијата е окупирана од Возачот на балон. Стандардно, драјверот за балон може да заземе до 65% од VM меморијата.

Ако VMware Tools не се инсталирани на VM или Balooning е оневозможено (не препорачувам, но има KB:), хипервизорот веднаш се префрла на построги техники за отстранување меморија. Заклучок: уверете се дека VMware Tools се на VM.

Работата на возачот на балон може да се провери од ОС преку VMware Tools.

компресија на меморија. Оваа техника се користи кога ESXi ќе достигне тврда состојба. Како што имплицира името, ESXi се обидува да намали 4KB страница на RAM меморија на 2KB и на тој начин да ослободи малку простор на физичката меморија на серверот. Оваа техника значително го зголемува времето на пристап до содржината на страниците на VM RAM меморијата, бидејќи страницата мора прво да се декомпресира. Понекогаш сите страници не можат да се компресираат и самиот процес трае некое време. Затоа, оваа техника не е многу ефикасна во пракса.

мемориска замена. По кратка фаза на компресија на меморијата, ESXi речиси неизбежно (ако VM-ите не заминале за други хостови или се исклучени) ќе се префрли на Swapping. И ако има многу малку меморија (Ниска состојба), тогаш хипервизорот исто така престанува да доделува мемориски страници на VM, што може да предизвика проблеми во гостинскиот оперативен систем на VM.

Еве како функционира Swapping. Кога ќе вклучите виртуелна машина, за неа се создава датотека со наставката .vswp. Таа е еднаква по големина на безрезервната RAM меморија на VM: тоа е разликата помеѓу конфигурирана и резервирана меморија. Кога Swapping работи, ESXi ги истоварува мемориските страници на виртуелната машина во оваа датотека и почнува да работи со неа наместо физичката меморија на серверот. Се разбира, таквата „оперативна“ меморија е неколку реда побавна од вистинската, дури и ако .vswp лежи на брзо складирање.

За разлика од Balooning, кога неискористените страници се земаат од VM, со Swapping, страниците што активно се користат од оперативниот систем или апликациите во VM можат да се префрлат на дискот. Како резултат на тоа, перформансите на VM паѓаат до точка на замрзнување. VM формално работи и барем може правилно да се оневозможи од оперативниот систем. Ако сте трпеливи 😉

Ако VM-ите отидоа на Swap, ова е ненормална ситуација, која најдобро е да се избегне ако е можно.

Клучни бројачи за перформанси на VM меморија

Така стигнавме до главната поента. За следење на состојбата на меморијата во VM, постојат следниве бројачи:

Активни — ја покажува количината на RAM (KB) до која VM имал пристап во претходниот период на мерење.

користење - исто како Active, но како процент од конфигурираната RAM меморија на VM. Пресметано со помош на следнава формула: активна ÷ конфигурирана големина на меморијата на виртуелната машина.
Високата употреба и Активното, соодветно, не се секогаш индикатор за проблеми со перформансите на VM. Ако VM агресивно користи меморија (барем добива пристап до неа), тоа не значи дека нема доволно меморија. Наместо тоа, тоа е повод да се види што се случува во ОС.
Постои стандарден аларм за употреба на меморија за VM:

Дели - количината на VM RAM меморија дедупликирана со TPS (во внатрешноста на VM или помеѓу VMs).

Доделено - количината на физичка меморија на домаќинот (KB) што му беше дадена на VM. Вклучува споделено.

Консумирани (Грантирано - споделено) - количината на физичка меморија (KB) што VM ја троши од домаќинот. Не вклучува споделено.

Ако дел од VM меморијата е даден не од физичката меморија на домаќинот, туку од датотеката за размена, или меморијата е земена од VM преку двигателот на балон, оваа сума не се зема предвид во Доделени и потрошени.
Високите доделени и потрошени вредности се сосема нормални. Оперативниот систем постепено ја зема меморијата од хипервизорот и не ја враќа назад. Со текот на времето, во активно работи VM, вредностите на овие бројачи се приближуваат до количината на конфигурирана меморија и остануваат таму.

Нула — количината на VM RAM (KB), која содржи нули. Таквата меморија се смета за бесплатна од хипервизорот и може да се даде на други виртуелни машини. Откако гостинскиот оперативен систем ќе напише нешто на нула меморија, тој оди во Consumed и не се враќа назад.

Резервирани надземни — износот на VM RAM, (KB) резервиран од хипервизорот за работа со VM. Ова е мала сума, но мора да биде достапна на домаќинот, инаку VM нема да започне.

Балон — износот на RAM меморија (KB) запленет од ВМ со помош на возачот на балон.

Компресиран - количеството на RAM меморија (KB) што беше компресирана.

Заменет - количината на RAM (KB) што поради недостаток на физичка меморија на серверот се пресели на дискот.
Бројачите на балон и други техники за мелиорација на меморијата се нула.

Вака изгледа графикот со бројачи на меморија за нормално работен VM со 150 GB RAM.

На графиконот подолу, VM има очигледни проблеми. Под графиконот можете да видите дека за овој VM се користени сите опишани техники за работа со RAM меморија. Балон за овој VM е многу поголем од потрошен. Всушност, ВМ е повеќе мртов отколку жив.

ESXTOP

Како и кај процесорот, ако сакаме брзо да ја процениме ситуацијата на домаќинот, како и неговата динамика со интервал до 2 секунди, треба да користиме ESXTOP.

Екранот ESXTOP од меморија се повикува со копчето „m“ и изгледа вака (се избираат полињата B, D, H, J, K, L, O):

Следниве параметри ќе бидат од интерес за нас:

Мем прекумерно обврзување просечно - просечната вредност на претплата на меморијата на домаќинот за 1, 5 и 15 минути. Ако е над нулата, тогаш ова е повод да се види што се случува, но не секогаш показател за проблеми.

Во редови PMEM/MB и ВМКМЕМ/МБ - информации за физичката меморија на серверот и меморијата достапна за VMkernel. Од интересното овде можете да ја видите вредноста на minfree (во MB), состојбата на домаќинот во меморијата (во нашиот случај, висока).

Во линија NUMA/MB можете да ја видите дистрибуцијата на RAM меморијата по NUMA јазли (сокети). Во овој пример, распределбата е нерамномерна, што, во принцип, не е многу добро.

Следното е општа статистика на серверот за техниките за рекултивација на меморијата:

PSHARE/MB се TPS статистика;

SWAP/MB — статистика за користење на замена;

ZIP/MB — статистика за компресија на мемориски страници;

MEMCTL/MB — Статистика за користење на возачот на балон.

За поединечни VMs, може да нè интересираат следните информации. Ги скрив имињата на ВМ за да не ја збунам публиката :). Ако метриката ESXTOP е слична на бројачот во vSphere, го давам соодветниот бројач.

MEMSZ — количината на меморија конфигурирана на VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + недопрено.

ДОДАЈТЕ - Доделено на М.Б.

TCHD — Активен во МБ.

MCTL? - дали Балон Драјвер е инсталиран на VM.

MCTLSZ — Балон до МБ.

MCTLGT — количината на RAM (MB) што ESXi сака да ја земе од VM преку Балон Драјвер (Memctl Target).

MCTLMAX - максималниот износ на RAM (MB) што ESXi може да го земе од VM преку двигателот на балон.

SWCUR — моменталната количина на RAM (MB) доделена на VM од датотеката Swap.

S.W.G.T. - износот на RAM (MB) што ESXi сака да му го даде на VM од датотеката Swap (Swap Target).

Исто така, преку ESXTOP, можете да видите подетални информации за NUMA топологијата на VM. За да го направите ова, изберете ги полињата D, G:

МАЛИ – NUMA јазли на кои се наоѓа VM. Овде можете веднаш да забележите широк vm, кој не се вклопува на еден NUMA јазол.

NRMEM - колку мегабајти меморија зема VM од оддалечениот NUMA јазол.

НЛМЕМ - колку мегабајти меморија зема VM од локалниот NUMA јазол.

N%L – процент на VM меморија на локалниот NUMA јазол (ако е помал од 80%, може да се појават проблеми со изведбата).

Меморија на хипервизорот

Ако бројачите на процесорот за хипервизорот обично не се од особен интерес, тогаш ситуацијата се менува со меморијата. Високата употреба на меморија на VM не секогаш укажува на проблем со перформансите, но високата употреба на меморија на хипервизорот активира техники за управување со меморијата и предизвикува проблеми со перформансите во VM. Алармите за користење на меморијата на домаќинот мора да се следат за да се спречи VM да влезе во Swap.

разменуваат

Ако VM е во Swap, неговите перформанси се значително намалени. Трагите од Balloning и компресија брзо исчезнуваат откако ќе се појави слободната RAM меморија на домаќинот, но виртуелната машина не брза да се врати од Swap на RAM-от на серверот.
Пред ESXi 6.0, единствениот сигурен и брз начин да се извади VM од Swap беше да се рестартира (да бидам попрецизен, исклучете/вклучете го контејнерот). Почнувајќи со ESXi 6.0, иако не е сосема официјален, се појави работен и сигурен начин за отстранување на VM од Swap. На една од конференциите, можев да разговарам со еден од инженерите на VMware задолжен за распоредувачот на процесорот. Тој потврди дека методот е доста работен и безбеден. Според нашето искуство, ниту со тоа немаше проблеми.

Вистинските команди за отстранување на VM од Swap опишан Данкан Епинг. Нема да повторам детален опис, само дајте пример за неговата употреба. Како што можете да видите на екранот, некое време по извршувањето на наведените команди, Swap исчезнува на VM.

Совети за управување со меморијата ESXi

Конечно, еве неколку совети кои ќе ви помогнат да избегнете проблеми со перформансите на VM поради RAM меморијата:

• Избегнувајте преголема претплата на меморијата во продуктивни кластери. Пожелно е секогаш да има ~20-30% слободна меморија во кластерот, така што DRS (и администраторот) имаат простор за маневрирање, а VM-ите да не влегуваат во Swap за време на миграцијата. Исто така, не заборавајте за маржата за толеранција на грешки. Непријатно е кога, кога еден сервер не успее и VM се рестартира со помош на HA, некои од машините исто така влегуваат во Swap.
• Во високо консолидирани инфраструктури, обидете се да НЕ создавате VM со повеќе од половина од меморијата на домаќинот. Ова повторно ќе му помогне на DRS да ги дистрибуира виртуелните машини низ кластерските сервери без никакви проблеми. Ова правило, се разбира, не е универзално :).
• Гледајте за аларм за употреба на меморија на домаќинот.
• Не заборавајте да инсталирате VMware Tools на VM и не исклучувајте го Balooning.
• Размислете за овозможување Inter-VM TPS и оневозможување на големи страници во VDI и тест околини.
• Ако VM се соочува со проблеми со перформансите, проверете дали користи меморија од оддалечен NUMA јазол.
• Отстранете го вашиот VM од Swap што е можно побрзо! Меѓу другото, ако VM е во Swap, од очигледни причини, системот за складирање страда.

Тоа е сè за мене за RAM меморијата. Подолу е поврзана статија за оние кои сакаат да копаат во детали. Следната статија ќе биде посветена на storadzh.

Корисни линковиhttp://www.yellow-bricks.com/2015/03/02/what-happens-at-which-vsphere-memory-state/
http://www.yellow-bricks.com/2013/06/14/how-does-mem-minfreepct-work-with-vsphere-5-0-and-up/
https://www.vladan.fr/vmware-transparent-page-sharing-tps-explained/
http://www.yellow-bricks.com/2016/06/02/memory-pages-swapped-can-unswap/
https://kb.vmware.com/s/article/1002586
https://www.vladan.fr/what-is-vmware-memory-ballooning/
https://kb.vmware.com/s/article/2080735
https://kb.vmware.com/s/article/2017642
https://labs.vmware.com/vmtj/vmware-esx-memory-resource-management-swap
https://blogs.vmware.com/vsphere/2013/10/understanding-vsphere-active-memory.html
https://www.vmware.com/support/developer/converter-sdk/conv51_apireference/memory_counters.html
https://docs.vmware.com/en/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-65-monitoring-performance-guide.pdf

Извор: www.habr.com