У гэтым артыкуле пагаворым пра лічыльнікі прадукцыйнасці аператыўнай памяці (RAM) у vSphere.
Накшталт бы з памяццю ўсё больш адназначна, чым з працэсарам: калі на ВМ узнікаюць праблемы з прадукцыйнасцю, іх складана не заўважыць. Затое калі яны з'яўляюцца, зладзіцца з імі значна складаней. Але пра ўсё па парадку.
крыху тэорыі
Аператыўная памяць віртуальных машын бярэцца з памяці сервера, на якіх працуюць ВМ. Гэта цалкам відавочна:). Калі аператыўнай памяці сервера не хапае для ўсіх жадаючых, ESXi пачынае прымяняць тэхнікі аптымізацыі спажывання аператыўнай памяці (memory reclamation techniques). У адваротным выпадку аперацыйныя сістэмы ВМ падалі б з памылкамі доступу да АЗП.
Якія тэхнікі ўжываць ESXi вырашае ў залежнасці ад загружанасці аператыўнай памяці:
Стан памяці
мяжа
Дзеянні
высокая
400% ад minFree
Пасля дасягнення верхняй мяжы, вялікія старонкі памяці разбіваюцца на маленькія (TPS працуе ў стандартным рэжыме).
ясна
100% ад minFree
Вялікія старонкі памяці разбіваюцца на маленькія, TPS працуе прымусова.
Мяккі
64% ад minFree
TPS + Balloon
Жорсткі
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, то ў ВМ, якія працуюць на ім, сапраўды назіраюцца праблемы з прадукцыйнасцю.
У кожным стане прымяняюцца пэўныя memory reclamation techniques пачынаючы з TPS, практычна не ўплывае на прадукцыйнасць ВМ, заканчваючы Swapping'ом. Раскажу пра іх падрабязней.
Transparent Page Sharing (TPS). TPS – гэта, груба кажучы, дэдуплікацыя старонак аператыўнай памяці віртуальных машын на серверы.
ESXi шукае аднолькавыя старонкі аператыўнай памяці віртуальных машын, лічачы і параўноўваючы hash-суму старонак, і выдаляе дублікаты старонак, замяняючы іх спасылкамі на адну і тую ж старонку ў фізічнай памяці сервера. У выніку спажыванне фізічнай памяці зніжаецца і можна дабіцца некаторай перападпіскі па памяці практычна без зніжэння прадукцыйнасці.
Дадзены механізм працуе толькі для старонак памяці памерам 4 Кбайт (small pages). Старонкі памерам 2 МБайт (large pages) гіпервізар дэдуплікаваць нават не спрабуе: шанец знайсці аднолькавыя старонкі такога памеру не вялікі.
Па змаўчанні ESXi вылучае памяць вялікім старонкам. Разбіванне вялікіх старонак на маленькія пачынаецца пры дасягненні парога стану High і адбываецца прымусова, калі дасягаецца стан Clear (гл. табліцу станаў гіпервізара).
Калі ж вы хочаце, каб TPS пачынаў працу, не чакаючы запаўнення аператыўнай памяці хаста, у Advanced Options ESXi трэба ўсталяваць значэнне "Mem.AllocGuestLargePage" у 0 (па змаўчанні 1). Тады вылучэнне вялікіх старонак памяці для віртуальных машын будзе адключана.
Са снежня 2014 года ва ўсіх рэлізах ESXi TPS паміж ВМ па змаўчанні адключаны, бо была знойдзена ўразлівасць, якая тэарэтычна дазваляе атрымаць з адной ВМ доступ да аператыўнай памяці іншай ВМ. Падрабязнасці тут. Інфармацыя пра практычную рэалізацыю эксплуатацыі ўразлівасці TPS мне не сустракалася.
Палітыка TPS кантралюецца праз advanced option "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. Ballooning ужо не такая бяскрыўдная і празрыстая для аперацыйнай сістэмы ВМ тэхніка, як TPS. Але пры пісьменным ужыванні з Ballooning'ам можна жыць і нават працаваць.
Разам з Vmware Tools на ВМ усталёўваецца спецыяльны драйвер, званы Balloon Driver (ён жа vmmemctl). Калі гіпервізару пачынае бракаваць фізічнай памяці і ён пераходзіць у стан Soft, ESXi просіць ВМ вярнуць невыкарыстоўваную аператыўную памяць праз гэты Balloon Driver. Драйвер у сваю чаргу працуе на ўзроўні аперацыйнай сістэмы і запытвае свабодную памяць у яе. Гіпервізар бачыць, якія старонкі фізічнай памяці заняў Balloon Driver, забірае памяць у віртуальнай машыны і вяртае хасту. Праблем з працай АС не ўзнікае, бо на ўзроўні АС памяць занятая Balloon Driver'ом. Па змаўчанні Balloon Driver можа забраць да 65% памяці ВМ.
Калі на ВМ не ўстаноўлены VMware Tools або адключаны Ballooning (не рэкамендую, але ёсць :), гіпервізор адразу пераходзіць да больш цвёрдым тэхнікам адабрання памяці. Выснова: сочыце, каб VMware Tools на ВМ былі.
Працу Balloon Driver'а можна праверыць з АС праз VMware Tools.
Memory Compression. Дадзеная тэхніка прымяняецца, калі ESXi даходзіць да стану Hard. Як вынікае з назвы, ESXi спрабуе сціснуць 4 Кбайт старонкі аператыўнай памяці да 2 Кбайт і такім чынам вызваліць крыху месцы ў фізічнай памяці сервера. Дадзеная тэхніка значна павялічвае час доступу да змесціва старонак аператыўнай памяці ВМ, бо старонку трэба папярэдне расціснуць. Часам не ўсе старонкі ўдаецца сціснуць і сам працэс займае некаторы час. Таму дадзеная тэхніка на практыцы не вельмі эфектыўная.
Memory Swapping. Пасля нядоўгай фазы Memory Compression ESXi практычна непазбежна (калі ВМ не з'ехалі на іншыя хасты ці не выключыліся) пераходзіць да Swapping'у. А калі памяці засталося зусім мала (стан Low), то гіпервізар таксама перастае вылучаць ВМ старонкі памяці, што можа выклікаць праблемы ў гасцявых АС ВМ.
Вось як працуе Swapping. Пры ўключэнні віртуальнай машыны для яе ствараецца файл з пашырэннем .vswp. Па памеры ён роўны незарэзерваванай аператыўнай памяці ВМ: гэта розніца паміж сканфігураванай і зарэзерваванай памяццю. Пры працы Swapping'а ESXi выгружае старонкі памяці віртуальнай машыны ў гэты файл і пачынае працаваць з ім замест фізічнай памяці сервера. Зразумела, такая такая "аператыўная" памяць на некалькі парадкаў павольней сапраўднай, нават калі .vswp ляжыць на хуткім сховішчы.
У адрозненне ад Ballooning'а, калі ў ВМ адбіраюцца старонкі, якія не выкарыстоўваюцца, пры Swapping'e на дыск могуць пераехаць старонкі, якія актыўна выкарыстоўваюцца АС або прыкладаннямі ўнутры ВМ. У выніку прадукцыйнасць ВМ падае аж да падвісанні. ВМ фармальна працуе і яе прынамсі можна правільна адключыць з АС. Калі вы будзеце цярплівыя 😉
Калі ВМ сышлі ў Swap - гэта няштатная сітуацыя, якую па магчымасці лепш не дапускаць.
Асноўныя лічыльнікі прадукцыйнасці памяці віртуальнай машыны
Вось мы і дабраліся да галоўнага. Для маніторынгу стану памяці ў ВМ ёсць наступныя лічыльнікі:
Актыўны - Паказвае аб'ём аператыўнай памяці (Кбайт), да якога ВМ атрымала доступ у папярэдні перыяд вымярэння.
Выкарыстанне - тое ж, што Active, але ў працэнтах ад сканфігураванай аператыўнай памяці ВМ. Разлічваецца па наступнай формуле: active ÷ virtual machine configured memory size.
Высокі Usage і Active, адпаведна, не заўсёды з'яўляецца паказчыкам праблем прадукцыйнасці ВМ. Калі ВМ агрэсіўна выкарыстоўвае памяць (як мінімум, атрымлівае да яе доступ), гэта не значыць, што памяці не хапае. Хутчэй за гэта нагода паглядзець, што адбываецца ў АС.
Ёсць стандартны Alarm па Memory Usage для ВМ:
Агульныя - аб'ём аператыўнай памяці ВМ, дэдуплікаваны з дапамогай TPS (унутры ВМ або паміж ВМ).
прадстаўлены - аб'ём фізічнай памяці хаста (Кбайт), які быў аддадзены ВМ. Уключае Shared.
Спажываецца (Granted – Shared) – аб'ём фізічнай памяці (Кбайт), якую ВМ спажывае з хаста. Не ўключае Shared.
Калі частка памяці ВМ аддаецца не з фізічнай памяці хаста, а з swap-файла ці памяць адабрана ў ВМ праз Balloon Driver, дадзены аб'ём не ўлічваецца ў Granted і Consumed.
Высокія значэнні Granted і Consumed - гэта зусім нармальна. Аперацыйная сістэма паступова забірае памяць у гіпервізара і не аддае зваротна. З часам у актыўна якая працуе ВМ значэнні дадзеных лічыльнікаў набліжаецца да аб'ёму сканфігураванай памяці, і тамака застаюцца.
Нулявы - аб'ём аператыўнай памяці ВМ (Кбайт), які змяшчае нулі. Такая памяць лічыцца гіпервізарам свабоднай і можа быць аддадзена іншым віртуальным машынам. Пасля таго, як гасцёўня АС атрымала запісала штосьці ў зануленую памяць, яна пераходзіць у Consumed і зваротна ўжо не вяртаецца.
Reserved Overhead - аб'ём аператыўнай памяці ВМ, (Кбайт) зарэзерваваны гіпервізарам для працы ВМ. Гэта невялікі аб'ём, але ён абавязкова павінен быць у наяўнасці на хасце, інакш ВМ не запусціцца.
Паветраны шар - аб'ём аператыўнай памяці (Кбайт), канфіскаванай у ВМ з дапамогай Balloon Driver.
Сціснуты - аб'ём аператыўнай памяці (Кбайт), якую ўдалося сціснуць.
Абмяняліся - аб'ём аператыўнай памяці (Кбайт), якая па адсутнасці фізічнай памяці на серверы пераехала на дыск.
Balloon і астатнія лічыльнікі memory reclamation techniques роўныя нулю.
Вось так выглядае графік са лічыльнікамі Memory звычайна якая працуе ВМ са 150 ГБ аператыўнай памяці.
На графіцы ніжэй у ВМ відавочныя праблемы. Пад графікам відаць, што для дадзенай ВМ былі скарыстаны ўсе апісаныя тэхнікі працы з аператыўнай памяццю. Balloon для дадзенай ВМ моцна больш, чым Consumed. Па факце ВМ хутчэй мёртвая, чым жывая.
ESXTOP
Як і з CPU, калі жадаем аператыўна ацаніць сітуацыю на хасце, а таксама яе дынаміку з інтэрвалам да 2 секунд, варта скарыстацца ESXTOP.
Экран ESXTOP па Memory выклікаецца клавішай "m" і выглядае наступным чынам (выбраныя палі B, D, H, J, K, L, O):
Цікавымі для нас будуць наступныя параметры:
Mem overcommit avg - сярэдняе значэнне перападпіскі па памяці на хасце за 1, 5 і 15 хвілін. Калі вышэй за нуль, то гэта нагода паглядзець, што адбываецца, але не заўсёды паказчык наяўнасці праблем.
У радках PMEM/MB и VMKMEM/MB - інфармацыя аб фізічнай памяці сервера і памяці даступнай VMkernel. З цікавага тут можна ўбачыць значэнне minfree (у МБайт), стан хаста па памяці (у нашым выпадку, high).
У радку NUMA/MB можна ўбачыць размеркаванне аператыўнай памяці па NUMA-нодам (сокетам). У дадзеным прыкладзе размеркаванне нераўнамернае, што ў прынцыпе не вельмі добрае.
Далей ідзе агульная статыстыка па сэрвэры па memory reclamation techniques:
PSHARE/MB - Гэта статыстыка TPS;
SWAP/MB - статыстыка выкарыстання Swap;
ZIP/MB - статыстыка кампрэсіі старонак памяці;
MEMCTL/MB - Статыстыка выкарыстання Balloon Driver.
Па асобных ВМ нас можа зацікавіць наступная інфармацыя. Імёны ВМ я схаваў, каб не бянтэжыць аўдыторыю:). Калі метрыка ESXTOP аналагічная лічыльніку ў vSphere, прыводжу які адпавядае лічыльнік.
MEMSZ - аб'ём памяці, сканфігураваны на ВМ (МБ).
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.
ГРАНТ - 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:
МАЛЫЯ - NUMA вузлы, на якіх размешчана ВМ. Тут можна адразу заўважыць wide vm, якія не змяшчаюцца на адзін NUMA вузел.
NRMEM - колькі мегабайт памяці ВМ бярэ з выдаленага NUMA вузла.
NLMEM - колькі мегабайт памяці ВМ бярэ з лакальнага NUMA вузла.
N%L – працэнт памяці ВМ на лакальным NUMA вузле (калі менш за 80% – могуць узнікнуць праблемы з прадукцыйнасцю).
Memory на гіпервізоры
Калі лічыльнікі 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'у без праблем размяркоўваць віртуальныя машыны па серверах кластара. Гэтае правіла, зразумела, не ўніверсальнае :).
- Сачыце за Host Memory Usage Alarm.
- Не забывайце ставіць на ВМ VMware Tools і не выключайце Ballooning.
- Разгледзьце магчымасць уключэння Inter-VM TPS і выключэнні Large Pages у асяроддзях з VDI і тэставых асяроддзях.
- Калі ВМ адчувае праблемы з прадукцыйнасцю, праверце не выкарыстоўвае Ці яна памяць з выдаленай NUMA-ноды.
- Выводзіце ВМ з Swap як мага хутчэй! Акрамя ўсяго іншага, калі ВМ у Swap'е, па відавочных прычынах пакутуе СГД.
На гэтым пра аператыўную памяць у мяне ўсё. Ніжэй артыкула па тэме для тых, хто хоча паглыбіцца ў дэталі. Наступны артыкул будзе прысвечаны стараду.
Карысныя спасылкі
Крыніца: habr.com