В тази статия ще разгледаме счетчиците за производителността на оперативната памет (RAM) в vSphere.
Изглежда, че с паметта всичко е по-ясно, отколкото с процесора: ако на ВМ има проблеми с производителността, те трудно остават незабелязани. Но ако възникнат, справянето с тях е много по-трудно. Но да започнем отначало.
Няколко теории
Оперативната памет на виртуалните машини идва от паметта на сървърите, на които работят ВМ. Това е доста очевидно :). Ако оперативната памет на сървъра не е достатъчна за всички заявки, ESXi започва да прилага техники за оптимизация на потреблението на оперативна памет (memory reclamation techniques). В противен случай, операционните системи на ВМ биха се сриварали с грешки за достъп до RAM.
Какви техники да прилага ESXi се решава в зависимост от натоварването на оперативната памет:
Състояние на паметта
Граница
Действия
High
400% от minFree
След достигане на горната граница, големите страници памет се разбиват на малки (TPS работи в стандартен режим).
Изчисти
100% от minFree
Големите страници памет се разбиват на малки, TPS работи принудително.
Мек
64% от minFree
TPS + Balloon
Твърд
32% от minFree
TPS + Compress + Swap
Low
16% от minFree
Compress + Swap + Block
minFree е оперативната памет, необходима за работата на хипервизора.
До ESXi 4.1 включително, minFree по подразбиране беше фиксирано — 6% от обема на оперативната памет на сървера (процентът можеше да бъде променян чрез опцията Mem.MinFreePct на ESXi). В по-късните версии, поради увеличаване на обемите на паметта на сървърите, minFree започна да се изчислява на базата на обема на паметта на хоста, а не като фиксирано процентно значение.
Стойността на minFree (по подразбиране) се изчислява по следния начин:
Процент на паметта, резервиран за minFree
Диапазон памет
6%
0-4 Гбайта
4%
4-12 Гбайта
2%
12-28 Гбайта
1%
Оставена памет
Например, за сървър с 128 Гбайта RAM стойността MinFree ще бъде такава:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 Мбайта = 1,88 Гбайта
Фактическата стойност може да се различава с няколко стотин МБ, в зависимост от сървъра и оперативната памет.
Процент на паметта, резервиран за minFree
Диапазон памет
Стойност за 128 Гбайта
6%
0-4 Гбайта
245,76 Мбайта
4%
4-12 Гбайта
327,68 Мбайта
2%
12-28 Гбайта
327,68 Мбайта
1%
Оставена памет (100 Гбайта)
1024 Мбайта
Обикновено за продуктивни среди нормално се счита състоянието High. За среди за тестване и разработка приемливи могат да бъдат състоянията Clear/Soft. Ако наличната оперативна памет на хоста е под 64% MinFree, то при ВМ, работещи на него, определено ще се наблюдават проблеми с производителността.
Във всяко състояние се прилагат определени техники за възстановяване на памет, започвайки от TPS, практически не влияещ на производителността на ВМ, до Swapping. Ще разкажа за тях по-подробно.
Transparent Page Sharing (TPS). TPS е, грубо казано, дедупликация на страниците на оперативната памет на виртуалните машини на сървера.
ESXi търси еднакви страници на оперативната памет на виртуалните машини, счита и сравнява хеш-сумите на страниците и премахва дубликатите, заменяйки ги с връзки към една и съща страница в физическата памет на сървера. В резултат на това консумацията на физическа памет намалява и може да бъде постигната известна повторна подписка на паметта почти без спад в производителността.
Този механизъм работи само за страници с размер 4 Кбайта (малки страници). Страници с размер 2 МБайт (големи страници) хипервизорът изобщо не се опитва да дедуплицира: шансът да намери идентични страници с такъв размер не е голям.
По подразбиране ESXi разпределя памет на големите страници. Разделянето на големи страници на малки започва при достигане на прага на състояние High и става принудително, когато се достигне състояние Clear (вж. таблицата на състоянията на хипервизора).
Ако желаете TPS да започне работа, без да изчаква запълването на оперативната памет на хоста, в Advanced Options на ESXi трябва да зададете стойността “Mem.AllocGuestLargePage” на 0 (по подразбиране 1). Тогава разпределението на големи страници памет за виртуални машини ще бъде изключено.
От декември 2014 г. във всички версии на ESXi TPS между ВМ по подразбиране е изключен, тъй като беше открита уязвимост, теоретично позволяваща достъп от една ВМ до оперативната памет на друга ВМ. Подробности тук. Информация за практическото реализиране на експлоатация на уязвимостта TPS не съм срещал.
Политиката TPS се контролира чрез разширената опция “Mem.ShareForceSalting” на ESXi:
0 — Inter-VM TPS. TPS работи за страници от различни ВМ;
1 – TPS за ВМ с еднаква стойност “sched.mem.pshare.salt” в VMX;
2 (по подразбиране) – Intra-VM TPS. TPS работи за страници вътре в ВМ.
Определено има смисъл да се изключват големи страници и да се включва Inter-VM TPS на тестовите среди. Това може да се използва и за среди с голямо количество еднотипни ВМ. Например, в среди с VDI спестяването на физическа памет може да достигне десетки проценти.
Паметно балониране. Балонирането вече не е толкова безобидна и прозрачна техника за операционната система на ВМ, като TPS. Но при правилно приложение, с балонирането може да се живее и дори да се работи.
Вместо VMware Tools на ВМ се инсталира специален драйвер, наречен Balloon Driver (или vmmemctl). Когато хипервизорът започне да страда от липса на физическа памет и премине в състояние Soft, ESXi иска от ВМ да върне неизползваната оперативна памет чрез този Balloon Driver. Драйверът на свой ред работи на ниво операционна система и иска свободна памет от нея. Хипервизорът вижда, кои страници физическа памет е заел Balloon Driver, отнема памет от виртуалната машина и я връща на хоста. Проблеми с работата на ОС не възникват, тъй като на ниво ОС паметта е заета от Balloon Driver. По подразбиране Balloon Driver може да отнеме до 65% от паметта на ВМ.
Ако на ВМ не са инсталирани VMware Tools или балонирането е деактивирано (не препоръчвам, но има :), хипервизорът веднага преминава към по-строги техники за отнемане на памет. Извод: следете, за да сте сигурни, че VMware Tools на ВМ са инсталирани.
Работата на Balloon Driver може да се провери от ОС чрез VMware Tools..
Компресия на паметта. Тази техника се прилага, когато ESXi достигне състояние Hard. Както подсказва името, ESXi се опитва да компресира 4 Кбайт страница оперативна памет до 2 Кбайт и по този начин да освободи малко място в физическата памет на сървъра. Тази техника значително увеличава времето за достъп до съдържанието на страниците оперативна памет на ВМ, тъй като страницата трябва предварително да се декомпресира. Понякога не всички страници успяват да се компресират и самият процес отнема известно време. Затова тази техника на практика не е много ефективна.
Суйпинг на паметта. След кратка фаза на компресия на паметта, ESXi практически неизбежно (ако ВМ не са преместени на други хостове или не са изключени) преминава към суйпинг. А ако остава малко памет (състояние Low), хипервизорът също спира да разпределя на ВМ страници памет, което може да предизвика проблеми в гостуващите ОС на ВМ.
Така работи Swapping. Когато виртуалната машина се включи, за нея се създава файл с разширение .vswp. Размерът му е равен на незаетата оперативна памет на ВМ: разликата между конфигурираната и резервираната памет. По време на работата на Swapping, ESXi записва страниците на паметта на виртуалната машина в този файл и започва да работи с него вместо с физическата памет на сървъра. Разбира се, такава "оперативна" памет е многократно по-бавна от истинската, дори ако .vswp е на бързо хранилище.
В отличие от Ballooning, при което на ВМ се отнемат неизползвани страници, при Swapping на диска могат да отидат страници, които активно се използват от ОС или приложенията в рамките на ВМ. В резултат на това производителността на ВМ спада до зависване. ВМ формално работи и може да се изключи правилно от ОС. Ако бъдете търпеливи 😉
Ако ВМ е в Swap — това е необичайна ситуация, която по възможност е по-добре да не се допуска.
Основните метрики за производителност на паметта на виртуалната машина
Ето ни и при основната точка. За мониторинг на състоянието на паметта в ВМ има следните метрики:
Активен — показва обема на оперативната памет (КБ), до който ВМ е имала достъп за предишния период на измерване.
Използване — същото като Active, но в проценти от конфигурираната оперативна памет на ВМ. Изчислява се по следната формула: active ÷ размер на конфигурираната памет на виртуалната машина.
Високото Използване и Active не винаги е показател за проблеми с производителността на ВМ. Ако ВМ агресивно използва памет (поне има достъп до нея), това не означава, че паметта е недостатъчна. По-скоро е повод да се види какво се случва в ОС.
Има стандартен Аларм за Използване на Паметта за ВМ:
Shared — обемът на оперативната памет на ВМ, дедублициран с помощта на TPS (вътре в ВМ или между ВМ).
Предоставено — обемът на физическата памет на хоста (КБ), който е предоставен на ВМ. Включва Shared.
Стартирана (Предоставено — Shared) — обемът на физическата памет (КБ), която ВМ консумира от хоста. Не включва Shared.
Ако част от паметта на ВМ се предоставя не от физическата памет на хоста, а от swap файл или паметта се отнема от ВМ чрез Balloon Driver, този обем не се отчита в Предоставената и Консумирана.
Високите стойности Granted и Consumed са напълно нормални. Операционната система постепенно отбелязва паметта от хипервизора и не я връща обратно. С времето, стойностите на тези индикатори за активно работеща ВМ наближават обема на конфигурираната памет и остават там.
Нула — обемът на оперативната памет на ВМ (Кбайт), който съдържа нули. Тази памет се счита от хипервизора за свободна и може да бъде предоставена на други виртуални машини. След като гостуващата ОС запише нещо в занулената памет, тя преминава в Consumed и не се връща обратно.
Запазен Излишък — обемът на оперативната памет на ВМ (Кбайт), резервиран от хипервизора за работа на ВМ. Това е малък обем, но той задължително трябва да бъде наличен на хоста; в противен случай ВМ няма да стартира.
Balloon — обемът на оперативната памет (Кбайт), изтеглен от ВМ с помощта на Balloon Driver.
Стисната — обемът на оперативната памет (Кбайт), който е успял да бъде компресиран.
Обменена — обемът на оперативната памет (Кбайт), който, при липса на физическа памет на сървъра, е преместен на диск.
Balloon и останалите индикатори за техники за възстановяване на паметта са равни на нула.
Така изглежда графиката с индикаторите на нормално работеща ВМ с 150 ГБ оперативна памет.
На графиката по-долу ВМ има явни проблеми. Под графиката е видно, че за тази ВМ са използвани всички описани техники за работа с оперативна памет. Balloon за тази ВМ е много по-голям от Consumed. Всъщност ВМ е по-скоро мъртва, отколкото жива.
ESXTOP
Както и с CPU, ако искаме бързо да оценим ситуацията на хоста, а също така нейната динамика с интервал до 2 секунди, е добре да използваме ESXTOP.
Екранът на ESXTOP за памет се извиква с клавиша "m" и изглежда по следния начин (избрани полета B,D,H,J,K,L,O):
Интересни за нас ще бъдат следните параметри:
Средно нападение на паметта — средното значение на надписването на паметта на хоста за 1, 5 и 15 минути. Ако е над нула, това е повод да погледнем какво се случва, но не всегда е индикатор за наличие на проблеми.
В редовете PMEM/MB и VMKMEM/MB — информация за физическата памет на сървъра и паметта, достъпна за VMkernel. От интерес може да се види стойността minfree (в Мегабайти), състоянието на хоста по отношение на паметта (в нашия случай, високо).
В реда NUMA/MB може да видите разпределението на оперативната памет по NUMA-нодове (сокети). В този пример разпределението е неравномерно, което не е много добре.
Следва общата статистика на сървъра относно техниките за възстановяване на паметта:
PSHARE/MB — е статистика на TPS;
SWAP/MB — статистика за използването на Swap;
ZIP/MB — статистика за компресия на страници в паметта;
MEMCTL/MB — статистика за използването на Balloon Driver.
За отделните ВМ може да ни интересува следната информация. Имената на ВМ съм скрил, за да не обърквам аудиторията :). Ако метриката ESXTOP е аналогична на брояча във vSphere, представям съответния брояч.
MEMSZ — обемът на паметта, конфигуриран за ВМ (МБ).
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.
GRANT — Granted в Мегабайти.
TCHD — Active в Мегабайти.
MCTL? — установен ли е на ВМ Balloon Driver.
MCTLSZ — Balloon в Мегабайти.
MCTLGT — обемът на оперативната памет (Мегабайти), който ESXi иска да изземе от ВМ през Balloon Driver (Memctl Target).
MCTLMAX — максималният обем оперативна памет (Мегабайти), който ESXi може да изземе от ВМ през Balloon Driver.
SWCUR — текущият обем оперативна памет (Мегабайти), предоставен на ВМ от Swap файла.
SWGT — обемът оперативна памет (Мегабайти), който ESXi иска да предостави на ВМ от Swap файла (Swap Target).
Също така, чрез ESXTOP можете да видите по-подробна информация относно NUMA топологията на ВМ. За това трябва да изберете полетата D,G:
NHN – NUMA възли, на които е разположена ВМ. Тук може да забележите wide vm, които не се побират на един NUMA възел.
NRMEM – колко мегабайта памет ВМ взима от отдалечен NUMA възел.
NLMEM – колко мегабайта памет ВМ взима от локален NUMA възел.
N%L – процент на паметта на ВМ на локалния NUMA възел (ако е под 80% — могат да възникнат проблеми с производителността).
Памет на хипервизора
Ако брояча на CPU по хипервизора обикновено не представлява особен интерес, то с паметта ситуацията е обратна. Високото Memory Usage на ВМ не винаги сочи проблем с производителността, но високото Memory Usage на хипервизора задейства техники за управление на паметта и предизвиква проблеми с производителността на ВМ. Трябва да следим алармите за Host Memory Usage и да не допускаме ВМ да попадне в Swap.
Unswap
Ако ВМ е попаднала в Swap, производителността й рязко спада. Следите от Ballooning и компресия бързо изчезват след появата на свободна оперативна памет на хоста, а виртуалната машина не бърза да се върне от Swap в оперативната памет на сървъра.
До версия ESXi 6.0 единственият надежден и бърз начин за извеждане на ВМ от Swap беше рестартирането (по-точно изключването/включването на контейнера). Започвайки от ESXi 6.0, се появи, макар и не съвсем официален, но работещ и надежден начин за извеждане на ВМ от Swap. На една от конференциите успях да се срещна с един от инженерите на VMware, който отговаря за CPU Scheduler. Той потвърди, че този метод е напълно работещ и безопасен. В нашия опит също не бяха установени проблеми с него.
Командите за извеждане на ВМ от Swap Duncan Epping. Няма да повтарям подробното описание, просто ще дам пример за нейното използване. Както се вижда на скрийншота, след известно време след изпълнението на указаната команда, Swap на ВМ изчезва.
Съвети за управление на оперативната памет на ESXi
Накрая ще дам няколко съвета, които ще ви помогнат да избегнете проблеми с производителността на ВМ заради оперативната памет:
- Не допускайте пренасищане с оперативна памет в продуктивни клъстери. Препоръчително е винаги да имате около 20-30% свободна памет в клъстера, за да има пространство за маневри, както за DRS, така и за администратора, и при миграцията на ВМ да не се отиде в Swap. Също така не забравяйте за запасите за отказоустойчивост. Неприятно е, когато при изключване на един сървър и рестартиране на ВМ чрез HA, част от машините още отидат в Swap.
- В инфраструктури с висока консолидираност, старайте се ДА не създавате ВМ с памет, по-голяма от половината от паметта на хоста. Това отново ще помогне на DRS без проблеми да разпределя виртуалните машини по сървърите на клъстера. Това правило, разбира се, не е универсално.
- Следете алармата за използване на оперативната памет на хоста.
- Не забравяйте да инсталирате VMware Tools на ВМ и не деактивирайте Ballooning.
- Помислете за възможността за включване на Inter-VM TPS и изключване на Large Pages в среди с VDI и тестови среди.
- Ако ВМ има проблеми с производителността, проверете дали използва памет с отдалечена NUMA-нода.
- Извеждайте ВМ от Swap колкото е възможно по-бързо! Освен всичко друго, ако ВМ е в Swap, по очевидни причини страда СХД.
Това е всичко за оперативната памет от моя страна. По-долу ще намерите статии по темата за тези, които искат да навлязат в детайлите. Следващата статия ще бъде посветена на сториджа.
Полезни връзки
Източник: habr.com
