В тази статия ще говорим за броячи на производителността на оперативната памет (RAM) в vSphere.
Изглежда, че с паметта всичко е по-ясно, отколкото с процесора: когато на ВМ възникват проблеми с производителността, трудно е да не ги забележите. Но ако се появят, справянето с тях е много по-сложно. Но всичко по ред.
Няколко теории
Оперативната памет на виртуалните машини идва от паметта на сървъра, на който работят ВМ. Това е напълно очевидно :). Ако на сървъра не стига оперативна памет за всички желаещи, ESXi започва да прилага техники за оптимизация на потреблението на оперативна памет (memory reclamation techniques). В противен случай операционните системи на ВМ биха пада с грешки при достъп до RAM.
Какви техники да прилага, ESXi решава в зависимост от натовареността на оперативната памет:
Състояние на паметта
Граница
Действия
Високо
400% от minFree
След достигане на горната граница, големите страници оперативна памет се разделят на малки (TPS работи в стандартен режим).
Изчисти
100% от minFree
Големите страници оперативна памет се разделят на малки, TPS работи принудително.
Soft
64% от minFree
TPS + Balloon
Hard
32% от minFree
TPS + Compress + Swap
Ниско
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, спестяването на физическа памет може да достигне десетки проценти.
Memory Ballooning. Балонният метод вече не е толкова безобиден и прозрачен за операционната система на виртуалната машина, както 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 ÷ размер на конфигурираната памет на виртуалната машина.
Високото Използване и Active не винаги са показател за проблеми с производителността на ВМ. Ако ВМ агресивно използва памет (поне получава достъп до нея), това не означава, че паметта не достига. Скорее това е повод да се види какво се случва в ОС.
Има стандартен Аларм за Използване на паметта за ВМ:
Споделен — обем на оперативната памет на ВМ, дублирана с помощта на TPS (вътре в ВМ или между ВМ).
Предоставено — обем на физическата памет на хоста (КБ), който е предоставен на ВМ. Включва Shared.
Консумирано (Granted — Shared) — обем на физическата памет (КБ), която ВМ консумира от хоста. Не включва Shared.
Ако част от паметта на ВМ се предоставя не от физическата памет на хоста, а от swap файла или паметта е отнета от ВМ чрез Balloon Driver, този обем не се отчита в Granted и Consumed.
Високите стойности на Granted и Consumed са напълно нормални. Операционната система постепенно отнема памет от хипервизора и не я връща обратно. С течение на времето стойностите на тези показатели при активно работеща виртуална машина достигат обема на конфигурираната памет и там остават.
Нула — обемът на оперативната памет на ВМ (Кбайт), който съдържа нули. Тази памет се счита от хипервизора за свободна и може да бъде предоставена на други виртуални машини. След като гостуващата ОС запише нещо в нулираната памет, тя преминава в Consumed и вече не се връща обратно.
Резервиран накладен обем — обемът на оперативната памет на ВМ (Кбайт), резервиран от хипервизора за работа на ВМ. Това е малък обем, но той задължително трябва да бъде наличен на хостa, иначе ВМ няма да се стартира.
Балон — обемът на оперативната памет (Кбайт), иззет от ВМ с помощта на Balloon Driver.
Сжата — обемът на оперативната памет (Кбайт), който е успял да бъде компресиран.
Обменена — обемът на оперативната памет (Кбайт), която поради недостатъчна физическа памет на сървъра е преместена на диск.
Балонът и останалите показатели на техниките за възстановяване на паметта са равни на нула.
Така изглежда графикът с показателите на нормално работеща ВМ с 150 ГБ оперативна памет.
На графика по-долу ВМ има явни проблеми. Под графика е видно, че за тази ВМ са използвани всички описани техники за работа с оперативната памет. Балонът за тази ВМ е значително по-голям от Consumed. Всъщност ВМ е по-скоро мъртва, отколкото жива.
ESXTOP
Както и при CPU, ако искаме бързо да оценим ситуацията на хостa, както и динамиката му с интервал до 2 секунди, е добре да използваме ESXTOP.
Екранът ESXTOP по памет се извиква с клавиш "m" и изглежда по следния начин (избрани са полетата B,D,H,J,K,L,O):
Интересни за нас ще бъдат следните параметри:
Средно значение на надписването на паметта — средното значение на надписването на паметта на хостa за 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 възли, на които е разположена ВМ. Тук веднага може да се забележи широката ВМ, която не може да се побере на един NUMA възел.
NRMEM – колко мегабайта памет ВМ взима от отдалечен NUMA възел.
NLMEM – колко мегабайта памет ВМ взима от локален NUMA възел.
N%L – процент на паметта на ВМ на локален NUMA възел (ако е по-малко от 80% — може да възникнат проблеми с производителността).
Памет на хипервизора
Ако броячите на CPU на хипервизора обикновено не представляват особен интерес, то при паметта ситуацията е обратна. Високото използване на паметта на ВМ не винаги говори за наличие на проблем с производителността, но високото използване на паметта на хипервизора задейства техника за управление на паметта и предизвиква проблеми с производителността на ВМ. Трябва да се следят алармите за използването на паметта на хост и да не се допуска попадането на ВМ в Swap.
Unswap
Ако ВМ е попаднала в Swap, нейното представяне значително намалява. Следите от Ballooning и компресия бързо изчезват след появата на свободна оперативна памет на хоста, но виртуалната машина не бърза да се върне от Swap в оперативната памет на сървера.
До версия ESXi 6.0 единственият надежден и бърз начин за извеждане на ВМ от Swap беше рестартиране (по-точно изключване и включване на контейнера). Започвайки от ESXi 6.0, се появи макар и не напълно официален, но работещ и надежден начин за извеждане на ВМ от Swap. На една от конференциите успях да разговарям с един от инженерите на VMware, който отговаря за CPU Scheduler. Той потвърди, че методът е напълно работещ и безопасен. В нашия опит не сме забелязали проблеми с него.
Собствено команди за извеждане на ВМ от Swap Дункан Епинг. Не ще повтарям подробното описание, просто ще дам пример за използването му. Както се вижда на скрийншота, след известно време след изпълнението на указаната команда Swap на ВМ изчезва.
Съвети за управление на оперативната памет на ESXi
Накрая ще дам няколко съвета, които ще ви помогнат да избегнете проблеми с производителността на ВМ поради оперативна памет:
- Не допускайте прехвърляне на оперативна памет в продуктивни клъстъри. Желателно е винаги да имате около 20-30% свободна памет в клъстера, за да има пространство за маневри у DRS (и у администратора), като по този начин ВМ не преминават в Swap при миграция. Също така не забравяйте за резерв за отказоустойчивост. Неприятно е, когато при повреда на един сървър и рестартиране на ВМ с помощта на HA част от машините също преминават в Swap.
- В инфраструктури с висока консолидираност се стремете да НЕ създавате ВМ с памет над половината от паметта на хоста. Това отново ще помогне на DRS без проблеми да разпределя виртуалните машини между сървърите в клъстера. Това правило, разбира се, не е универсално :).
- Следете за алармата за използване на паметта на хоста.
- Не забравяйте да инсталирате VMware Tools на ВМ и не изключвайте Ballooning.
- Помислете за включване на Inter-VM TPS и изключване на Large Pages в среди с VDI и тестови среди.
- Ако ВМ изпитва проблеми с производителността, проверете дали не използва памет от отдалечен NUMA-нод.
- Извеждайте ВМ от Swap възможно най-бързо! Освен всичко друго, ако ВМ е в Swap, по очевидни причини страда СХД.
На това за оперативната памет от мен е всичко. По-долу статии по темата за тези, които искат да се задълбочат в детайлите. Следващата статия ще бъде посветена на стораджа.
Полезни линкове
Източник: habr.com
