Бул макалада биз vSphereдеги кокустук эстутумдун (RAM) иштөө эсептегичтери жөнүндө сүйлөшөбүз.
Эстутум менен процессорго караганда баары түшүнүктүү окшойт: эгерде VMде иштөөдө көйгөйлөр болсо, аларды байкабай коюу кыйын. Бирок алар пайда болсо, алар менен күрөшүү бир топ кыйын. Бирок биринчи кезекте.
теориясынын бир үзүм
Виртуалдык машиналардын оперативдик эс тутуму VM иштеп жаткан сервердин эс тутумунан алынат. Бул абдан ачык :). Эгерде сервердин оперативдүү эс тутуму баарына жетишсиз болсо, ESXi оперативдик эстутум керектөөсүн оптималдаштыруу үчүн эстутумду калыбына келтирүү ыкмаларын колдоно баштайт. Болбосо, VM операциялык тутумдары RAM кирүү каталары менен бузулуп калат.
ESXi кандай ыкмаларды колдонууну RAMдын жүгүнө жараша чечет:
Эстутум абалы
чек ара
Действия
бийик
400% акысыз
Жогорку чекке жеткенден кийин, чоң эстутум барактары кичинекейлерге бөлүнөт (TPS стандарттык режимде иштейт).
ачык
100% акысыз
Чоң эстутум барактары кичинекейлерге бөлүнүп, TPS иштөөгө аргасыз.
жумшак
64% акысыз
TPS + Шар
катуу
32% акысыз
TPS + Компресс + Алмашуу
төмөн
16% акысыз
Компресс + Алмашуу + Блок
minFree - бул гипервизордун иштеши үчүн зарыл болгон RAM.
ESXi 4.1 камтылганга чейин, minFree демейки боюнча бекитилген - сервердин оперативдүү эс тутумунун 6% (пайызды ESXiдеги Mem.MinFreePct опциясы аркылуу өзгөртүүгө болот). Кийинки версияларда серверлерде эстутум көлөмүнүн көбөйүшүнө байланыштуу, minFree белгиленген пайыз катары эмес, хосттун эс тутумунун көлөмүнө жараша эсептеле баштады.
minFree (демейки) мааниси төмөнкүдөй эсептелет:
minFree үчүн сакталган эстутумдун пайызы
Эстутум диапазону
6%
0-4 ГБ
4%
4-12 ГБ
2%
12-28 ГБ
1%
Калган эс
Мисалы, 128 ГБ оперативдик эс тутуму бар сервер үчүн MinFree мааниси:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 МБ = 1,88 ГБ
Чыныгы маани бир нече жүз МБ менен айырмаланышы мүмкүн, ал серверге жана RAMга жараша болот.
minFree үчүн сакталган эстутумдун пайызы
Эстутум диапазону
128 ГБ үчүн баа
6%
0-4 ГБ
245,76 MB
4%
4-12 ГБ
327,68 MB
2%
12-28 ГБ
327,68 MB
1%
Калган эстутум (100 ГБ)
1024 MB
Адатта, өндүрүмдүү стенддер үчүн Жогорку абалды гана нормалдуу деп эсептесе болот. Сыноо жана өнүктүрүү отургучтары үчүн Clear/Soft абалдары кабыл алынышы мүмкүн. Эгерде хосттогу RAM 64% MinFreeден аз болсо, анда иштеген VM'лерде сөзсүз түрдө иштөө көйгөйлөрү бар.
Ар бир штатта эстутумду калыбына келтирүүнүн белгилүү ыкмалары колдонулат, TPSден баштап, VMнин иштешине дээрлик эч кандай таасир этпейт жана Свопингге чейин. Мен алар жөнүндө көбүрөөк айтып берем.
Transparent Page Sharing (TPS). TPS, болжол менен айтканда, сервердеги виртуалдык машинанын эстутум барактарынын көчүрмөсү.
ESXi виртуалдык машинанын оперативдик эс тутумунун окшош баракчаларын барактардын хэш суммасын эсептөө жана салыштыруу аркылуу издейт жана кайталанма барактарды жок кылып, аларды сервердин физикалык эс тутумундагы бир эле баракка шилтемелер менен алмаштырат. Натыйжада, физикалык эстутум керектөө азаят жана кээ бир эстутумдун ашыкча жазылуусуна аз же такыр иштебей коюу менен жетишүүгө болот.
Бул механизм 4 КБ эстутум барактары (кичинекей баракчалар) үчүн гана иштейт. Гипервизор 2 МБ (чоң барактар) барактарды дедупировкалоого да аракет кылбайт: бул өлчөмдөгү окшош баракчаларды табуу мүмкүнчүлүгү чоң эмес.
Демейки боюнча, ESXi чоң барактарга эстутумду бөлөт. Чоң барактарды кичинекей барактарга бөлүү Жогорку абал босогосуна жеткенде башталат жана Таза абалга жеткенде мажбурланат (гипервизордун абалы таблицасын караңыз).
Эгер сиз TPS хост RAMдын толушун күтпөстөн иштей башташын кааласаңыз, ESXi Advanced Options ичинде сиз маанини коюшуңуз керек. “Mem.AllocGuestLargePage” 0гө (демейки 1). Андан кийин виртуалдык машиналар үчүн чоң эстутум баракчаларын бөлүштүрүү өчүрүлөт.
2014-жылдын декабрынан бери ESXiнин бардык чыгарылыштарында VM ортосундагы TPS демейки боюнча өчүрүлгөн, анткени бир VMден башка VMнин оперативдүү эс тутумуна теориялык жактан кирүүгө мүмкүндүк берген аялуу жер табылган. Чоо-жайы бул жерде. Мен TPSтин алсыздыгын колдонуунун практикалык ишке ашырылышы жөнүндө маалыматка жолуга элекмин.
TPS саясаты өркүндөтүлгөн опция аркылуу көзөмөлдөнөт "Mem.ShareForceSalting" ESXi боюнча:
0 - Inter-VM TPS. TPS ар кандай VM баракчалары үчүн иштейт;
1 – VMXде бирдей “sched.mem.pshare.salt” мааниси бар VM үчүн TPS;
2 (демейки) - Intra-VM TPS. TPS VM ичиндеги барактар үчүн иштейт.
Бул, албетте, чоң барактарды өчүрүү жана сыноо отургучтарында Inter-VM TPS күйгүзүү үчүн мааниси бар. Ал ошондой эле бир эле типтеги VM көп сандагы стенддер үчүн колдонулушу мүмкүн. Мисалы, VDI менен стенддерде физикалык эстутумда үнөмдөө ондогон пайызга жетиши мүмкүн.
эс шары. Шарды учуруу VM операциялык системасы үчүн TPS сыяктуу зыянсыз жана тунук техника эмес. Бирок туура колдонуу менен, сиз Ballooning менен жашап, ал тургай иштей аласыз.
Vmware Tools менен бирге VMге Balloon Driver (aka vmmemctl) деп аталган атайын драйвер орнотулган. Гипервизордун физикалык эс тутуму түгөнүп, Жумшак абалга киргенде, ESXi VMден пайдаланылбаган оперативдүү эстутумду ушул Balloon Driver аркылуу кайтарып алууну суранат. Драйвер, өз кезегинде, операциялык системанын деңгээлинде иштейт жана андан бош эстутумду сурайт. Гипервизор Balloon Driver физикалык эстутумдун кайсы барактарын ээлегенин көрөт, эстутумду виртуалдык машинадан алып, аны хостко кайтарат. ОСтун иштешинде эч кандай көйгөйлөр жок, анткени OS деңгээлинде эс тутумду Balloon Driver ээлейт. Демейки шартта Balloon Driver VM эс тутумунун 65% га чейин ээлей алат.
Эгерде VMware куралдары VMге орнотулбаса же шарлар өчүрүлгөн болсо (мен сунуш кылбайм, бирок бар :), гипервизор дароо эс тутумун жок кылуунун катаал ыкмаларына өтөт. Жыйынтык: VMware куралдары VMде экенин текшериңиз.
Balloon Driver'дын ишин VMware Tools аркылуу ОСтен текшерсе болот.
эс кысуу. Бул ыкма ESXi Катуу абалына жеткенде колдонулат. Аты айтып тургандай, ESXi RAMдын 4КБ барагын 2КБга кичирейтүүгө жана ошону менен сервердин физикалык эстутумунда бир аз орун бошотууга аракет кылат. Бул ыкма VM RAM барактарынын мазмунуна кирүү убактысын кыйла көбөйтөт, анткени бет алгач кысылышы керек. Кээде бардык барактар кысылышы мүмкүн эмес жана процесстин өзү бир аз убакытты талап кылат. Ошондуктан бул техника практикада анча эффективдүү эмес.
эс алмаштыруу. Кыска эстутумду кысуу фазасынан кийин, ESXi дээрлик сөзсүз түрдө (эгерде VM башка хостторго кетпесе же өчүрүлбөсө) Алмашууга өтөт. Ал эми эстутум өтө аз калса (Төмөн абал), анда гипервизор эстутум барактарын VMге бөлүштүрүүнү да токтотот, бул VMнин конок OSинде көйгөйлөрдү жаратышы мүмкүн.
Бул жерде Swapping кантип иштейт. Виртуалдык машинаны күйгүзгөндө, ал үчүн .vswp кеңейтүүсү менен файл түзүлөт. Ал VMнин сакталбаган оперативдик эс тутумуна өлчөмү боюнча барабар: бул конфигурацияланган жана сакталган эс тутумдун ортосундагы айырма. Swapping иштеп жатканда, ESXi бул файлга виртуалдык машина эстутум барактарын түшүрүп, сервердин физикалык эстутумунун ордуна аны менен иштей баштайт. Албетте, мындай "оперативдик" эс .vswp тез сактоо боюнча жатса да, реалдуу караганда жайыраак бир нече буйрук болуп саналат.
Ballooning айырмаланып, пайдаланылбаган барактар VMден алынганда, Swapping менен, OS же VM ичиндеги тиркемелер тарабынан жигердүү колдонулган барактар дискке жыла алат. Натыйжада, VMнин иштеши тоңуу деңгээлине чейин төмөндөйт. VM формалдуу түрдө иштейт жана жок дегенде аны OSден туура өчүрсө болот. Сабыр кылсаңыз 😉
Эгерде VM'лер Свопко барса, бул анормалдуу кырдаал, мүмкүн болсо, андан качуу керек.
Негизги VM эстутумунун аткаруу эсептегичтери
Ошентип, биз негизги ойго келдик. VMдеги эс тутумдун абалын көзөмөлдөө үчүн төмөнкү эсептегичтер бар:
активдүү — мурунку өлчөө мезгилинде VM кирүү мүмкүнчүлүгүнө ээ болгон RAM (КБ) көлөмүн көрсөтөт.
колдонуу - Active менен бирдей, бирок VM конфигурацияланган оперативдүү эс тутумунун пайызы катары. Төмөнкү формула менен эсептелген: активдүү ÷ виртуалдык машина конфигурацияланган эс өлчөмү.
Жогорку колдонуу жана активдүү, тиешелүүлүгүнө жараша, ар дайым VM аткаруу көйгөйлөрүнүн көрсөткүчү эмес. Эгерде VM эстутумду агрессивдүү түрдө колдонсо (жок дегенде ага мүмкүнчүлүк алса), бул эстутум жетишсиз дегенди билдирбейт. Тескерисинче, бул ОСте эмне болуп жатканын көрүү үчүн мүмкүнчүлүк.
VM үчүн стандарттуу эстутум колдонуу ойготкуч бар:
Бирге - TPS аркылуу дедупликацияланган VM RAM көлөмү (VM ичинде же VM ортосунда).
Албетте - VMге берилген физикалык хост эстутумунун көлөмү (КБ). Бөлүшүлгөн камтыйт.
керектелди (Берилген - Бөлүшүлгөн) - VM хосттон керектеген физикалык эстутумдун көлөмү (КБ). Бөлүшүлгөн камтылган эмес.
Эгерде VM эстутумунун бир бөлүгү хосттун физикалык эс тутумунан эмес, своп файлынан берилсе, же эстутум VMден Balloon Driver аркылуу алынса, бул сумма Берилген жана керектелгенде эске алынбайт.
Берилген жана керектелген баалуулуктар толугу менен нормалдуу. Операциялык система акырындык менен гипервизордон эстутумду алып, аны кайра бербейт. Убакыттын өтүшү менен жигердүү иштеген VMде бул эсептегичтердин маанилери конфигурацияланган эс тутумдун көлөмүнө жакындап, ошол жерде калат.
Нөл — нөлдөрдү камтыган VM RAM (КБ) көлөмү. Мындай эстутум гипервизор тарабынан бош деп эсептелет жана башка виртуалдык машиналарга берилиши мүмкүн. Конок ОС нөлдүк эстутумга бир нерсе жазгандан кийин, ал Consumed'ге кирет жана кайра кайтып келбейт.
Резервдик кошумча чыгымдар — VM иштеши үчүн гипервизор тарабынан сакталган VM RAM көлөмү, (КБ). Бул кичинекей сумма, бирок ал хостто жеткиликтүү болушу керек, антпесе VM башталбайт.
учуучу аба шары — Шар айдоочусу аркылуу VMден алынган оперативдүү эстутумдун көлөмү (КБ).
кысылган - кысылган оперативдик эстутумдун көлөмү (КБ).
Алмаштыруу - серверде физикалык эстутумдун жетишсиздигинен дискке которулган оперативдик эстутумдун көлөмү (КБ).
Шар жана башка эс мелиорациялоо техникаларынын эсептегичтери нөл.
150 ГБ оперативдик эс тутуму бар кадимки иштеген VM үчүн Эстутум эсептегичтери менен график ушундай көрүнөт.
Төмөнкү графикте VM айкын көйгөйлөргө ээ. Графиктин астында сиз бул VM үчүн RAM менен иштөө үчүн бардык сүрөттөлгөн ыкмалар колдонулганын көрө аласыз. Бул VM үчүн шар керектелгенден бир топ чоң. Чынында, VM тирүү караганда өлгөн.
ESXTOP
CPU сыяктуу эле, эгерде биз хосттогу кырдаалды, ошондой эле анын динамикасын 2 секундага чейинки аралык менен тез баалагыбыз келсе, ESXTOP колдонушубуз керек.
Memory тарабынан ESXTOP экраны "m" баскычы менен чакырылат жана мындай көрүнөт (B, D, H, J, K, L, O талаалары тандалган):
Төмөнкү параметрлер биз үчүн кызыктуу болот:
Мем орт - 1, 5 жана 15 мүнөткө хостто эстутум ашыкча жазылуунун орточо мааниси. Эгерде ал нөлдөн жогору болсо, анда бул эмне болуп жатканын көрүү үчүн мүмкүнчүлүк, бирок дайыма эле көйгөйлөрдүн көрсөткүчү эмес.
Саптарда PMEM/MB и VMKMEM/MB - сервердин физикалык эс тутуму жана VMkernel үчүн жеткиликтүү эстутум жөнүндө маалымат. Кызыктуу жерден сиз minfree маанисин (МБ менен), эс тутумдагы хосттун абалын (биздин учурда, жогорку) көрө аласыз.
Кезекте NUMA/MB NUMA түйүндөрү (розеткалар) боюнча RAMдын бөлүштүрүлүшүн көрө аласыз. Бул мисалда бөлүштүрүү бирдей эмес, бул, негизинен, анча жакшы эмес.
Төмөндө эстутумду калыбына келтирүү ыкмалары боюнча жалпы сервер статистикасы келтирилген:
PHARE/MB TPS статистикасы болуп саналат;
SWAP/MB — Колдонуу статистикасын алмаштыруу;
ZIP/MB — эстутум барагын кысуу статистикасы;
MEMCTL/MB — Balloon Driver колдонуу статистикасы.
Жеке VM'лер үчүн бизди төмөнкү маалымат кызыктырышы мүмкүн. Көрүүчүлөрдү чаташтырбоо үчүн VM аттарын жашырдым :). ESXTOP метрикасы vSphereдеги эсептегичке окшош болсо, мен тиешелүү эсептегичти берем.
MEMSZ — VMде конфигурацияланган эстутумдун көлөмү (МБ).
MEMSZ = GRANT + MCTLSZ + SWCUR + тийбеген.
ГРАНТ — МБга берилди.
TCHD — МБда активдүү.
MCTL? - VMде Balloon Driver орнотулганбы.
MCTLSZ — МБга шар.
MCTLGT — ESXi VMден Balloon Driver (Memctl Target) аркылуу алууну каалаган оперативдүү эстутумдун (МБ) көлөмү.
MCTLMAX - ESXi VMден Balloon Driver аркылуу ала турган RAMдын (МБ) максималдуу көлөмү.
SWCUR — Swap файлынан VMге бөлүнгөн RAMдын учурдагы көлөмү (МБ).
S.W.G.T. - Swap файлынан (Swap Target) ESXi VMге бергиси келген RAM (МБ) көлөмү.
Ошондой эле, ESXTOP аркылуу сиз VMдин NUMA топологиясы жөнүндө кеңири маалыматты көрө аласыз. Бул үчүн, D, G талааларын тандаңыз:
КИЧИ – VM жайгашкан NUMA түйүндөр. Бул жерде сиз дароо эле бир NUMA түйүнүнө туура келбеген кең VM байкай аласыз.
NRMEM - VM алыскы NUMA түйүнүнөн канча мегабайт эстутумду алат.
NLMEM - VM жергиликтүү NUMA түйүнүнөн канча мегабайт эстутумду алат.
N%L – жергиликтүү NUMA түйүнүндөгү VM эстутумунун пайызы (эгерде 80% дан аз болсо, аткаруу көйгөйлөрү пайда болушу мүмкүн).
Гипервизордогу эстутум
Эгерде гипервизордун CPU эсептегичтери адатта өзгөчө кызыкчылыкты туудурбаса, анда эстутум менен абал өзгөрөт. VMде эстутумдун көп колдонулушу ар дайым эле өндүрүмдүүлүк көйгөйүн көрсөтө бербейт, бирок гипервизордо эстутумдун жогору колдонулушу эстутумду башкаруу ыкмаларын иштетет жана VMде иштөө көйгөйлөрүн жаратат. VM Swapга кирүүсүнө жол бербөө үчүн Хост Эстутумун колдонуу сигналдары көзөмөлдөнүшү керек.
алмаштыруу
Эгерде VM Swap режиминде болсо, анын иштеши кыйла төмөндөйт. Хостта бош оперативдик эс пайда болгондон кийин шардын жана кысуунун издери тез эле жок болот, бирок виртуалдык машина Swapдан сервердин оперативдүү эсине кайтууга шашпайт.
ESXi 6.0ге чейин, Swapтан VMди алуунун бирден-бир ишенимдүү жана тез жолу кайра жүктөө болгон (тактап айтканда, контейнерди өчүрүү/күйгүзүү). ESXi 6.0 менен баштап, расмий эмес болсо да, Swapтан VMди алып салуунун жумушчу жана ишенимдүү жолу пайда болду. Конференциялардын биринде мен CPU Scheduler үчүн жооптуу VMware инженерлеринин бири менен сүйлөшө алдым. Ал бул ыкма абдан натыйжалуу жана коопсуз экенин тастыктады. Биздин тажрыйбабызда бул жагынан да эч кандай кыйынчылыктар болгон эмес.
VMди Своптан алып салуу үчүн чыныгы буйруктар Дункан Эпинг. Мен деталдуу сүрөттөлүштү кайталабайм, жөн гана анын колдонулушун мисал келтирейин. Скриншоттон көрүнүп тургандай, көрсөтүлгөн буйруктар аткарылгандан бир аз убакыт өткөндөн кийин, Swap VMде жок болот.
ESXi эс тутумун башкаруу боюнча кеңештер
Акыр-аягы, бул жерде RAMдан улам VM иштеши менен көйгөйлөрдөн качууга жардам бере турган кээ бир кеңештер:
- Жемиштүү кластерлерде эстутумга ашыкча жазылуудан качыңыз. Кластерде дайыма ~20-30% бош эстутум болушу керек, андыктан DRS (жана администратор) маневр жасоо үчүн орунга ээ жана VMлер миграция учурунда Swapга кирбеши керек. Ошондой эле, катага сабырдуулук үчүн маржа жөнүндө унутпа. Бир сервер иштебей калганда жана VM HA аркылуу кайра жүктөлгөндө, кээ бир машиналар Свопко киргенде жагымсыз.
- Жогорку консолидацияланган инфраструктураларда хосттун эстутумунун жарымынан көбүрөөгүн камтыган VMлерди түзбөөгө аракет кылыңыз. Бул дагы бир жолу DRSге виртуалдык машиналарды кластердик серверлер боюнча эч кандай көйгөйсүз таратууга жардам берет. Бул эреже, албетте, универсалдуу эмес :).
- Хосттун эстутумун колдонуу сигналын көрүңүз.
- VMге VMware куралдарын орнотууну унутпаңыз жана аба шарын өчүрбөңүз.
- VDI жана сыноо чөйрөлөрүндө Inter-VM TPSти иштетүүнү жана Large Pagesди өчүрүүнү карап көрүңүз.
- Эгерде VM иштөөдө көйгөйлөргө туш болуп жатса, ал алыскы NUMA түйүнүнүн эс тутумун колдонуп жатканын текшериңиз.
- VM'иңизди Swap'тан мүмкүн болушунча тезирээк алыңыз! Башка нерселер менен катар, эгерде VM Swapда болсо, белгилүү себептерден улам, сактоо тутуму жабыркайт.
Мунун баары мен үчүн RAM жөнүндө. Төмөндө майда-чүйдөсүнө чейин казууну каалагандар үчүн тиешелүү макала болуп саналат. Кийинки макала стораджга арналат.
Пайдалуу шилтемелер
Source: www.habr.com