В тази статия ще говорим за броячите на производителността на паметта с произволен достъп (RAM) във vSphere.
Изглежда, че с паметта всичко е по-ясно, отколкото с процесора: ако VM има проблеми с производителността, трудно е да не ги забележите. Но ако се появят, справянето с тях е много по-трудно. Но на първо място.
Малко теория
RAM паметта на виртуалните машини се взема от паметта на сървъра, на който работят виртуалните машини. Съвсем очевидно е :). Ако RAM на сървъра не е достатъчна за всички, ESXi започва да използва техники за възстановяване на паметта, за да оптимизира потреблението на RAM. В противен случай операционните системи на VM ще се сринат с грешки при достъп до RAM.
Кои техники да използвате ESXi решава в зависимост от натоварването на RAM:
Състояние на паметта
граница
Дейност
Високо
400% от minFree
След достигане на горната граница големите страници от паметта се разделят на малки (TPS работи в стандартен режим).
Изчисти
100% от minFree
Големите страници на паметта се разбиват на малки, TPS е принуден да работи.
мек
64% от minFree
TPS + балон
Трудно
32% от minFree
TPS + Компресиране + Размяна
ниско
16% от minFree
Компресиране + Размяна + Блокиране
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 ще бъде:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12MB = 1,88GB
Действителната стойност може да се различава с няколкостотин 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
Обикновено за продуктивни насаждения само високото състояние може да се счита за нормално. За стендовете за тестване и разработка може да са приемливи състояния Clear/Soft. Ако RAM на хоста е по-малко от 64% MinFree, тогава виртуалните машини, работещи на него, определено имат проблеми с производителността.
Във всяко състояние се прилагат определени техники за възстановяване на паметта, като се започне с TPS, което практически не влияе на производителността на VM и завършва с Swapping. Ще ви разкажа повече за тях.
Прозрачно споделяне на страници (TPS). TPS е, грубо казано, дедупликация на страници с памет на виртуална машина на сървър.
ESXi търси идентични страници от RAM на виртуалната машина, като брои и сравнява хеш сумата на страниците и премахва дублиращите се страници, заменяйки ги с връзки към същата страница във физическата памет на сървъра. В резултат на това потреблението на физическа памет е намалено и може да се постигне известен свръхабонамент за памет с малко или никакво влошаване на производителността.
Този механизъм работи само за страници с памет от 4 KB (малки страници). Хипервайзорът дори не се опитва да дедупира страници от 2 MB (големи страници): шансът да намерите идентични страници с този размер не е голям.
По подразбиране ESXi разпределя памет за големи страници. Разделянето на големи страници на малки страници започва, когато се достигне прагът на високо състояние и се налага, когато се достигне състоянието на изчистване (вижте таблицата със състоянието на хипервизора).
Ако искате TPS да започне да работи, без да чака RAM на хоста да се запълни, в Разширени опции ESXi трябва да зададете стойността „Mem.AllocGuestLargePage“ до 0 (по подразбиране 1). Тогава разпределението на големи страници с памет за виртуални машини ще бъде деактивирано.
От декември 2014 г., във всички версии на ESXi, TPS между VM е деактивиран по подразбиране, тъй като беше открита уязвимост, която теоретично позволява достъп от една VM до RAM на друга VM. Подробности тук. Не съм срещал информация за практическото прилагане на използването на TPS уязвимостта.
TPS политика, контролирана чрез разширена опция „Mem.ShareForceSalting“ на ESXi:
0 - Inter-VM TPS. TPS работи за страници от различни виртуални машини;
1 – TPS за VM със същата стойност „sched.mem.pshare.salt“ във VMX;
2 (по подразбиране) - Intra-VM TPS. TPS работи за страници във VM.
Определено има смисъл да изключите големите страници и да включите Inter-VM TPS на тестови стендове. Може да се използва и за стойки с голям брой еднотипни ВМ. Например, на стойки с VDI спестяванията във физическа памет могат да достигнат десетки проценти.
балон на паметта. Балонирането вече не е толкова безвредна и прозрачна техника за операционната система на VM като TPS. Но с правилно приложение можете да живеете и дори да работите с Ballooning.
Заедно с Vmware Tools, специален драйвер, наречен Balloon Driver (известен още като vmmemctl), е инсталиран на VM. Когато хипервайзорът започне да изчерпва физическата памет и влезе в състояние Soft, ESXi иска от VM да възстанови неизползваната RAM чрез този балонен драйвер. Драйверът от своя страна работи на ниво операционна система и иска свободна памет от нея. Хипервайзорът вижда кои страници от физическата памет е заел Balloon Driver, взема паметта от виртуалната машина и я връща на хоста. Няма проблеми с работата на ОС, тъй като на ниво ОС паметта е заета от Balloon Driver. По подразбиране Balloon Driver може да заема до 65% от VM паметта.
Ако VMware Tools не са инсталирани на VM или Ballooning е деактивиран (не препоръчвам, но има :), хипервайзорът веднага преминава към по-строги техники за премахване на паметта. Заключение: уверете се, че VMware Tools са на VM.
Работата на Balloon Driver може да се провери от операционната система чрез VMware Tools.
компресия на паметта. Тази техника се използва, когато ESXi достигне състояние Hard. Както подсказва името, ESXi се опитва да свие страница от 4KB RAM в 2KB и по този начин да освободи малко място във физическата памет на сървъра. Тази техника значително увеличава времето за достъп до съдържанието на страниците на VM RAM, тъй като страницата трябва първо да бъде декомпресирана. Понякога не всички страници могат да бъдат компресирани и самият процес отнема известно време. Следователно тази техника не е много ефективна на практика.
размяна на паметта. След кратка фаза на компресиране на паметта, ESXi почти неизбежно (ако виртуалните машини не са напуснали други хостове или са се изключили) ще премине към размяна. И ако остане много малко памет (ниско състояние), тогава хипервайзорът също спира да разпределя страници с памет към виртуалната машина, което може да причини проблеми в операционната система за гости на виртуалната машина.
Ето как работи размяната. Когато включите виртуална машина, за нея се създава файл с разширение .vswp. Тя е равна по размер на нерезервираната RAM на VM: това е разликата между конфигурираната и резервираната памет. Когато Swapping се изпълнява, ESXi разтоварва страници от паметта на виртуалната машина в този файл и започва да работи с него вместо с физическата памет на сървъра. Разбира се, такава „оперативна“ памет е с няколко порядъка по-бавна от реалната, дори ако .vswp е на бързо съхранение.
За разлика от Ballooning, когато неизползваните страници се вземат от VM, със Swapping, страниците, които се използват активно от операционната система или приложения във VM, могат да се преместят на диск. В резултат на това производителността на виртуалната машина пада до точката на замръзване. VM формално работи и поне може да бъде правилно деактивиран от операционната система. Ако сте търпеливи 😉
Ако виртуалните машини са преминали към Swap, това е необичайна ситуация, която е най-добре да се избягва, ако е възможно.
Ключови броячи на производителност на VM паметта
Така стигнахме до основното. За да наблюдавате състоянието на паметта във VM, има следните броячи:
Активен — показва количеството RAM (KB), до което VM е получила достъп през предишния период на измерване.
употреба - същото като Active, но като процент от конфигурираната RAM на VM. Изчислява се по следната формула: активен ÷ конфигуриран размер на паметта на виртуалната машина.
Висока употреба и съответно Active не винаги са индикатор за проблеми с производителността на VM. Ако VM агресивно използва памет (поне получава достъп до нея), това не означава, че няма достатъчно памет. По-скоро е повод да видим какво се случва в ОС.
Има стандартна аларма за използване на паметта за виртуални машини:
Обща - количеството VM RAM, дедупликирано с помощта на TPS (вътре в VM или между VM).
дадено - количеството физическа хост памет (KB), което е дадено на VM. Включва Shared.
Консумирана (Granted - Shared) - количеството физическа памет (KB), което VM консумира от хоста. Не включва Shared.
Ако част от VM паметта е дадена не от физическата памет на хоста, а от суап файла, или паметта е взета от VM чрез Balloon Driver, това количество не се взема предвид в Granted and Consumed.
Високите разрешени и консумирани стойности са напълно нормални. Операционната система постепенно отнема памет от хипервайзора и не я връща. С течение на времето, в активно работеща виртуална машина, стойностите на тези броячи се доближават до размера на конфигурираната памет и остават там.
нула — количеството VM RAM (KB), което съдържа нули. Такава памет се счита за свободна от хипервайзора и може да бъде предоставена на други виртуални машини. След като OS за гости е написала нещо в нулираната памет, тя отива в Consumed и не се връща обратно.
Запазени режийни разходи — количеството VM RAM (KB), запазено от хипервайзора за работа с VM. Това е малко количество, но трябва да е налично на хоста, в противен случай VM няма да стартира.
Балон — количеството RAM (KB), иззето от VM с помощта на балонния драйвер.
Сгъстеният - количеството RAM (KB), което е компресирано.
Разменят - количеството RAM (KB), което поради липса на физическа памет на сървъра е преместено на диск.
Броячите на балони и други техники за възстановяване на паметта са нула.
Ето как изглежда графиката с броячите на паметта за нормално работеща VM със 150 GB RAM.
В графиката по-долу VM има очевидни проблеми. Под графиката можете да видите, че за тази VM са използвани всички описани техники за работа с RAM. Балонът за тази виртуална машина е много по-голям от Consumed. Всъщност VM е повече мъртъв, отколкото жив.
ESXTOP
Както и при процесора, ако искаме бързо да оценим ситуацията на хоста, както и неговата динамика с интервал до 2 секунди, трябва да използваме ESXTOP.
Екранът ESXTOP от Memory се извиква с клавиша "m" и изглежда така (избрани са полета B, D, H, J, K, L, O):
Следните параметри ще представляват интерес за нас:
Mem overcommit ср - средната стойност на свръхабонамента на паметта на хоста за 1, 5 и 15 минути. Ако е над нулата, това е повод да видите какво се случва, но не винаги е индикатор за проблеми.
На редове PMEM/MB и VMKMEM/MB - информация за физическата памет на сървъра и наличната памет на VMkernel. От интересното тук можете да видите стойността на minfree (в MB), състоянието на хоста в паметта (в нашия случай високо).
В редица NUMA/MB можете да видите разпределението на RAM по NUMA възли (сокети). В този пример разпределението е неравномерно, което по принцип не е много добре.
Следното е обща сървърна статистика относно техниките за възстановяване на паметта:
PSHARE/MB са TPS статистики;
SWAP/MB — Статистика за използване на суап;
ZIP/MB — статистика за компресиране на страници от паметта;
MEMCTL/MB — Статистика за използване на Balloon Driver.
За отделни виртуални машини може да се интересуваме от следната информация. Скрих имената на ВМ, за да не обърквам аудиторията :). Ако показателят ESXTOP е подобен на брояча във vSphere, давам съответния брояч.
MEMSZ — количеството памет, конфигурирано на VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + недокоснат.
Дарение — Предоставено на MB.
TCHD — Активен в MB.
MCTL? - дали Balloon Driver е инсталиран на VM.
MCTLSZ — Балон до MB.
MCTLGT — количеството RAM (MB), което ESXi иска да вземе от VM чрез Balloon Driver (Memctl Target).
MCTLMAX - максималното количество RAM (MB), което ESXi може да вземе от VM чрез Balloon Driver.
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 възел.
NLMEM - колко мегабайта памет отнема VM от локалния NUMA възел.
N%L – процент на VM памет на локалния NUMA възел (ако е по-малко от 80%, могат да възникнат проблеми с производителността).
Памет на хипервайзора
Ако броячите на процесора за хипервайзора обикновено не представляват особен интерес, тогава ситуацията е обратна с паметта. Високото използване на паметта на VM не винаги показва проблем с производителността, но високото използване на паметта на хипервайзор задейства техники за управление на паметта и причинява проблеми с производителността на VM. Алармите за използване на паметта на хоста трябва да се наблюдават, за да се предотврати влизането на VM в Swap.
размяна
Ако VM е в Swap, нейната производителност е значително намалена. Следите от Ballooning и компресия бързо изчезват, след като на хоста се появи свободна RAM, но виртуалната машина не бърза да се върне от Swap към сървърната RAM.
Преди ESXi 6.0, единственият надежден и бърз начин да извадите VM от Swap беше рестартирането (за да бъдем по-точни, изключване/включване на контейнера). Започвайки с ESXi 6.0, макар и не съвсем официален, се появи работещ и надежден начин за премахване на VM от Swap. На една от конференциите успях да говоря с един от инженерите на VMware, отговарящ за CPU Scheduler. Той потвърди, че методът е доста работещ и безопасен. Според нашия опит също няма проблеми с него.
Действителните команди за премахване на VM от Swap Дънкан Епинг. Няма да повтарям подробно описание, просто дам пример за използването му. Както можете да видите на екранната снимка, известно време след изпълнението на посочените команди, Swap изчезва на VM.
Съвети за управление на паметта на ESXi
И накрая, ето няколко съвета, които ще ви помогнат да избегнете проблеми с производителността на VM поради RAM:
- Избягвайте свръхабонамента за памет в продуктивни клъстери. Желателно е винаги да имате ~20-30% свободна памет в клъстера, така че DRS (и администраторът) да имат място за маневриране и VM да не влизат в Swap по време на миграция. Също така не забравяйте за маржа за толерантност към грешки. Неприятно е, когато при отказ на един сървър и VM се рестартира чрез HA, някои от машините също влизат в Swap.
- В силно консолидирани инфраструктури, опитайте се да НЕ създавате виртуални машини с повече от половината памет на хоста. Това отново ще помогне на DRS да разпространява виртуални машини в сървърите на клъстера без никакви проблеми. Това правило, разбира се, не е универсално :).
- Следете за аларма за използване на паметта на хоста.
- Не забравяйте да инсталирате VMware Tools на виртуалната машина и не изключвайте Ballooning.
- Помислете дали да активирате Inter-VM TPS и да деактивирате Large Pages във VDI и тестови среди.
- Ако виртуалната машина изпитва проблеми с производителността, проверете дали използва памет от отдалечен NUMA възел.
- Извадете вашата VM от Swap възможно най-бързо! Освен всичко друго, ако VM е в Swap, по очевидни причини системата за съхранение страда.
Това е всичко за мен за RAM. По-долу е свързана статия за тези, които искат да се заровят в подробностите. Следващата статия ще бъде посветена на стораджа.
Полезни връзки
Източник: www.habr.com