Энэ нийтлэлд бид vSphere дахь санамсаргүй санах ойн (RAM) гүйцэтгэлийн тоолуурын талаар ярих болно.
Санах ойн хувьд процессортой харьцуулахад бүх зүйл илүү ойлгомжтой байх шиг байна: хэрэв VM-д гүйцэтгэлийн асуудал байгаа бол тэдгээрийг анзаарахгүй байх нь хэцүү байдаг. Гэхдээ хэрэв тэд гарч ирвэл тэдэнтэй харьцах нь илүү хэцүү болно. Гэхдээ хамгийн түрүүнд хийх зүйл.
Онол бага байна
Виртуал машинуудын RAM-ийг VM ажиллаж байгаа серверийн санах ойноос авдаг. Энэ нь ойлгомжтой :). Хэрэв серверийн RAM нь хүн бүрт хангалттай биш бол ESXi нь RAM-ийн хэрэглээг оновчтой болгохын тулд санах ойг нөхөн сэргээх арга техникийг ашиглаж эхэлдэг. Үгүй бол VM үйлдлийн системүүд RAM-д хандах алдаанаас болж гацах болно.
RAM-ийн ачааллаас хамааран ESXi ямар техникийг ашиглахаа шийднэ.
Санах ойн байдал
Хил
Үйлдэл
Өндөр
Минугийн 400% үнэгүй
Дээд хязгаарт хүрсний дараа санах ойн том хуудсууд жижиг хэсгүүдэд хуваагдана (TPS нь стандарт горимд ажилладаг).
Цэвэр
Минугийн 100% үнэгүй
Том санах ойн хуудсууд жижиг хэсгүүдэд хуваагдаж, TPS ажиллахаас өөр аргагүй болдог.
Зөөлөн
Минугийн 64% үнэгүй
TPS + Бөмбөлөг
Хатуу
Минугийн 32% үнэгүй
TPS + шахах + солих
Бага
Минугийн 16% үнэгүй
Шахах + Солих + Блок
minFree нь гипервизор ажиллахад шаардлагатай RAM юм.
ESXi 4.1-ийг багтаасан байхаас өмнө minFree-г анхдагч байдлаар зассан - серверийн RAM-ийн 6% (энэ хувийг ESXi дээрх Mem.MinFreePct сонголтоор өөрчилж болно). Сүүлчийн хувилбаруудад серверүүд дээрх санах ойн хэмжээ ихэссэнтэй холбоотойгоор 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,12MB = 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-ийн гүйцэтгэлд бараг нөлөөлдөггүй, Swapping хүртэл ашигладаг. Би тэдний талаар илүү ихийг хэлье.
Ил тод хуудас хуваалцах (TPS). TPS гэдэг нь ойролцоогоор хэлэхэд сервер дээрх виртуал машинуудын RAM хуудасны хуулбар юм.
ESXi нь хуудсуудын хэш нийлбэрийг тоолж, харьцуулах замаар ижил виртуал машины RAM хуудсыг хайж, давхардсан хуудсуудыг устгаж, серверийн физик санах ой дахь ижил хуудасны лавлагаагаар сольдог. Үүний үр дүнд физик санах ойн хэрэглээ багасч, гүйцэтгэлд ямар ч нөлөө үзүүлэхгүйгээр зарим санах ойн хэт их захиалгад хүрч болно.
Энэ механизм нь зөвхөн 4 KB санах ойн хуудас (жижиг хуудас) дээр ажилладаг. Гипервизор нь 2 МБ хэмжээтэй (том хуудас) хуудсыг задлах гэж оролддоггүй: ийм хэмжээтэй ижил хуудсыг олох боломж тийм ч их биш юм.
Анхдагчаар ESXi нь санах ойг том хуудсуудад хуваарилдаг. Том хуудсуудыг жижиг хуудас болгон хуваах нь Өндөр төлөвийн босгонд хүрэх үед эхэлдэг бөгөөд Clear төлөвт хүрэхэд албаддаг (гипервизорын төлөвийн хүснэгтийг үзнэ үү).
Хэрэв та хостын RAM-ыг дүүргэхийг хүлээлгүйгээр TPS-г ажиллуулж эхлэхийг хүсвэл ESXi Advanced Options-д утгыг тохируулах хэрэгтэй. “Mem.AllocGuestLargePage” 0 хүртэл (өгөгдмөл 1). Дараа нь виртуал машинуудад зориулсан том санах ойн хуудасны хуваарилалт идэвхгүй болно.
2014 оны XNUMX-р сараас хойш ESXi-ийн бүх хувилбаруудад нэг VM-ээс нөгөө VM-ийн RAM-д хандах боломжийг онолын хувьд олгодог эмзэг байдал илэрсэн тул VM-ийн хоорондох TPS-ийг анхдагч байдлаар идэвхгүй болгосон. Дэлгэрэнгүйг эндээс үзнэ үү. TPS-ийн эмзэг байдлыг ашиглах практик хэрэгжилтийн талаар би олж мэдээгүй байна.
TPS бодлогыг нэмэлт сонголтоор удирддаг “Mem.ShareForceSalting” ESXi дээр:
0 - 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-ээс ашиглагдаагүй RAM-г энэхүү Balloon Driver-аар дамжуулан эргүүлэн авахыг хүсдэг. Драйвер нь эргээд үйлдлийн системийн түвшинд ажилладаг бөгөөд үүнээс сул санах ой хүсдэг. Гипервизор нь Balloon Driver физик санах ойн аль хуудсуудыг эзэлснийг харж, санах ойг виртуал машинаас аваад хост руу буцаана. OS түвшинд санах ойг Balloon Driver эзэлдэг тул үйлдлийн системд ямар ч асуудал гарахгүй. Анхдагч байдлаар Balloon Driver нь VM санах ойн 65 хүртэлх хувийг эзэлдэг.
Хэрэв VMware Tools-ийг VM дээр суулгаагүй эсвэл Ballooning идэвхгүй бол (би санал болгохгүй, гэхдээ тэнд :), гипервизор тэр даруй санах ойг арилгах илүү хатуу аргад шилждэг. Дүгнэлт: VMware хэрэгслүүд VM дээр байгаа эсэхийг шалгаарай.
Balloon Driver-ийн ажиллагааг VMware Tools-ээр дамжуулан үйлдлийн системээс шалгаж болно.
санах ойн шахалт. Энэ аргыг ESXi хатуу төлөвт хүрэх үед ашигладаг. Нэрнээс нь харахад ESXi нь RAM-ийн 4KB хуудсыг 2KB болгон багасгахыг оролддог бөгөөд ингэснээр серверийн физик санах ойн зайг чөлөөлдөг. Энэ техник нь эхлээд хуудсыг задлах ёстой тул VM RAM хуудасны агуулгад хандах хугацааг ихээхэн нэмэгдүүлдэг. Заримдаа бүх хуудсыг шахах боломжгүй бөгөөд процесс өөрөө тодорхой хугацаа шаарддаг. Тиймээс энэ техник нь практикт тийм ч үр дүнтэй биш юм.
Санах ой солих. Богино санах ой шахах үе шат дууссаны дараа ESXi бараг гарцаагүй (хэрэв VM-ууд бусад хостууд руу яваагүй эсвэл унтраагаагүй бол) Swapping руу шилжих болно. Хэрэв санах ой маш бага үлдсэн бол (Бага төлөв) гипервизор нь санах ойн хуудсыг VM-д хуваарилахаа зогсоодог бөгөөд энэ нь VM-ийн зочин үйлдлийн системд асуудал үүсгэж болзошгүй юм.
Swapping хэрхэн ажилладаг талаар эндээс үзнэ үү. Виртуал машиныг асаахад .vswp өргөтгөлтэй файл үүснэ. Энэ нь VM-ийн нөөцгүй RAM-тай тэнцүү хэмжээтэй бөгөөд энэ нь тохируулсан болон нөөцлөгдсөн санах ойн ялгаа юм. Swapping ажиллаж байх үед ESXi нь виртуал машины санах ойн хуудсыг энэ файл руу буулгаж, серверийн физик санах ойн оронд түүнтэй ажиллаж эхэлдэг. Мэдээжийн хэрэг, ийм "үйл ажиллагааны" санах ой нь .vswp нь хурдан санах ойд байрладаг байсан ч бодитоос хэд хэдэн удаа удаан байдаг.
Ballooning-ээс ялгаатай нь ашиглагдаагүй хуудсыг VM-ээс авах үед Swapping-ийн тусламжтайгаар үйлдлийн систем эсвэл VM доторх програмууд идэвхтэй ашигладаг хуудсууд диск рүү шилжиж болно. Үүний үр дүнд VM-ийн гүйцэтгэл хөлдөх хүртэл буурдаг. VM нь албан ёсоор ажилладаг бөгөөд ядаж үүнийг үйлдлийн системээс зохих ёсоор идэвхгүй болгох боломжтой. Тэвчээртэй байвал 😉
Хэрэв VM-ууд Swap руу очсон бол энэ нь яаралтай нөхцөл байдал бөгөөд боломжтой бол зайлсхийх нь дээр.
VM санах ойн гүйцэтгэлийн гол тоолуур
Тиймээс бид гол зүйл рүүгээ орлоо. VM дээрх санах ойн төлөвийг хянахын тулд дараах тоолуур байдаг.
Идэвхтэй — өмнөх хэмжилтийн хугацаанд VM-ийн хандсан RAM (KB) хэмжээг харуулна.
Хэрэглээ — Идэвхтэй ижил, гэхдээ VM-ийн тохируулсан RAM-ийн хувиар. Дараах томъёог ашиглан тооцоолсон: идэвхтэй ÷ виртуал машин тохируулсан санах ойн хэмжээ.
Өндөр хэрэглээ ба идэвхтэй нь VM-ийн гүйцэтгэлийн асуудлын үзүүлэлт биш юм. Хэрэв VM нь санах ойг түрэмгий байдлаар ашигладаг бол (ядаж түүнд хандах боломжтой) энэ нь хангалттай санах ой байхгүй гэсэн үг биш юм. Үүний оронд энэ нь үйлдлийн системд юу болж байгааг харах боломж юм.
VM-д зориулсан стандарт санах ойн ашиглалтын дохиолол байдаг:
хуваалцсан - TPS ашиглан давхардсан VM RAM-ийн хэмжээ (VM дотор эсвэл VM хооронд).
Надад өгсөн - VM-д өгсөн физик хост санах ойн хэмжээ (KB). Хуваалцсан.
Хэрэглээ (Зөвлөгдсөн - Хуваалцсан) - VM-ийн хостоос ашигладаг физик санах ойн хэмжээ (KB). Хуваалцсаныг оруулаагүй болно.
Хэрэв VM санах ойн хэсэг нь хостын физик санах ойноос биш, харин своп файлаас өгөгдсөн эсвэл санах ойг VM-ээс Balloon Driver-аар дамжуулан авсан бол энэ хэмжээг "Өгөгдсөн ба хэрэглэсэн" хэсэгт тооцохгүй.
Өгөгдсөн болон хэрэглээний өндөр үнэ цэнэ нь туйлын хэвийн юм. Үйлдлийн систем нь гипервизороос санах ойг аажмаар авдаг бөгөөд буцааж өгдөггүй. Цаг хугацаа өнгөрөхөд идэвхтэй ажиллаж байгаа VM-д эдгээр тоолуурын утга нь тохируулсан санах ойн хэмжээнд ойртож, тэндээ үлддэг.
Тэг - тэг агуулсан VM RAM (KB) хэмжээ. Ийм санах ойг гипервизор үнэ төлбөргүй гэж үздэг бөгөөд бусад виртуал машинуудад өгч болно. Зочин үйлдлийн систем тэглэгдсэн санах ойд ямар нэгэн зүйл бичсэний дараа энэ нь Consumed руу орж буцаж ирэхгүй.
Нэмэлт зардал — VM-ийн үйл ажиллагаанд гипервизороос нөөцөлсөн VM RAM-ийн хэмжээ (KB). Энэ нь бага хэмжээ, гэхдээ энэ нь хост дээр байх ёстой, эс тэгвээс VM эхлэхгүй.
Бөмбөг - Balloon Driver ашиглан VM-ээс устгасан RAM (KB) хэмжээ.
Шахсан - шахагдсан RAM (KB) хэмжээ.
Солив - сервер дээр физик санах ой дутагдсанаас диск рүү шилжсэн RAM (KB) хэмжээ.
Бөмбөлөг болон бусад санах ойг нөхөн сэргээх техникийн тоолуур нь тэг байна.
Санах ойн тоолууртай график нь 150 ГБ RAM-тай хэвийн ажиллаж байгаа VM-ийн хувьд иймэрхүү харагдаж байна.
Доорх графикаас харахад VM нь тодорхой асуудлуудтай байна. Графикаас харахад энэ VM-ийн хувьд RAM-тай ажиллахад тайлбарласан бүх техникийг ашигласан болохыг харж болно. Энэ VM-д зориулсан бөмбөлөг нь Consumed-ээс хамаагүй том байна. Үнэн хэрэгтээ, VM амьд гэхээсээ илүү үхсэн.
ESXTOP
CPU-ийн нэгэн адил бид хост дээрх нөхцөл байдал, түүний динамикийг 2 секундын интервалтайгаар хурдан үнэлэхийг хүсвэл ESXTOP-ийг ашиглах хэрэгтэй.
Санах ойн ESXTOP дэлгэц нь "m" товчлуураар дуудагдах ба дараах байдалтай харагдана (B, D, H, J, K, L, O талбаруудыг сонгосон):
Дараахь параметрүүд бидний сонирхлыг татах болно.
Гишүүний дундаж хэмжээ хэтэрсэн - 1, 5, 15 минутын турш хост дээрх санах ойн хэт захиалгын дундаж утга. Хэрэв тэгээс дээш байвал энэ нь юу болж байгааг харах боломж юм, гэхдээ үргэлж асуудлын үзүүлэлт биш юм.
Шугам дотор PMEM/MB и VMKMEM/MB — серверийн физик санах ой болон VMkernel-д ашиглах боломжтой санах ойн тухай мэдээлэл. Сонирхолтой зүйлсийн дотроос та minfree утгыг (MB-ээр), санах ой дахь хост төлөвийг (манай тохиолдолд өндөр) харж болно.
Шугаманд NUMA/MB та NUMA зангилаа (сокет) -аар RAM-ийн хуваарилалтыг харж болно. Энэ жишээнд хуваарилалт жигд бус байгаа нь зарчмын хувьд тийм ч сайн биш юм.
Дараах нь санах ойг нөхөн сэргээх техникийн ерөнхий серверийн статистик юм.
PSHARE/MB нь TPS статистик;
SWAP/MB — Хэрэглээний статистикийг солих;
ZIP/MB — санах ойн хуудсыг шахах статистик;
MEMCTL/MB — Balloon Driver-ийн хэрэглээний статистик.
Хувь хүний VM-ийн хувьд бид дараах мэдээллийг сонирхож магадгүй юм. Үзэгчдийг төөрөгдүүлэхгүйн тулд VM-ийн нэрийг нуусан :). Хэрэв ESXTOP хэмжигдэхүүн нь vSphere дахь тоолууртай төстэй бол би тохирох тоолуурыг өгөх болно.
MEMSZ — VM (MB) дээр тохируулсан санах ойн хэмжээ.
MEMSZ = GRANT + MCTLSZ + SWCUR + хөндөгдөөгүй.
ТУСГАЛ - МБ-д олгосон.
TCHD - MB дээр идэвхтэй.
MCTL? - VM дээр Balloon Driver суулгасан эсэх.
MCTLSZ - МБ хүртэл бөмбөлөг.
MCTLGT — ESXi-ийн Balloon Driver (Memctl Target)-ээр дамжуулан VM-ээс авахыг хүссэн RAM (MB) хэмжээ.
MCTLMAX - Balloon Driver-аар дамжуулан ESXi-ийн VM-ээс авч болох хамгийн их хэмжээний RAM (MB).
SWCUR - Swap файлаас VM-д хуваарилагдсан одоогийн RAM (MB) хэмжээ.
S.W.G.T. - Swap файлаас (Swap Target) ESXi-ийн VM-д өгөхийг хүссэн RAM (MB) хэмжээ.
Мөн 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-д байгаа бол түүний гүйцэтгэл ихээхэн буурдаг. Хост дээр үнэгүй RAM гарч ирсний дараа агаарын бөмбөлөг болон шахалтын ул мөр хурдан арилдаг боловч виртуал машин нь Swap-аас серверийн RAM руу буцах гэж яарахгүй байна.
ESXi 6.0-аас өмнө VM-ийг Swap-аас гаргах цорын ганц найдвартай бөгөөд хурдан арга бол дахин ачаалах (илүү нарийвчлалтай бол контейнерийг унтраах/асаах) байсан. ESXi 6.0-аас эхлээд албан ёсны биш ч VM-г Swap-аас устгах найдвартай, найдвартай арга гарч ирэв. Чуулгануудын нэг дээр би CPU Scheduler хариуцсан VMware инженерүүдийн нэгтэй ярилцаж чадсан. Энэ арга нь нэлээд үр дүнтэй, аюулгүй гэдгийг тэрээр баталжээ. Бидний туршлагаас харахад үүнтэй холбоотой ямар ч асуудал гараагүй.
Свопоос VM-г устгах бодит тушаалууд Дункан Эпинг. Би нарийвчилсан тайлбарыг давтахгүй, зүгээр л ашиглах жишээг өг. Дэлгэцийн зургаас харахад заасан тушаалуудыг гүйцэтгэсний дараа хэсэг хугацааны дараа Swap нь VM дээр алга болно.
ESXi дээрх RAM-г удирдах зөвлөмжүүд
Эцэст нь, RAM-аас болж VM-ийн гүйцэтгэлтэй холбоотой асуудлаас зайлсхийхэд туслах хэдэн зөвлөмжийг энд оруулав.
- Бүтээмжтэй кластеруудад санах ойг хэтрүүлэн захиалахаас зайлсхий. DRS (болон администратор) маневр хийх зайтай байхын тулд кластерт үргэлж ~20-30% сул санах ойтой байх нь зүйтэй бөгөөд VM-ууд шилжих явцад Swap руу орохгүй. Мөн алдааг тэсвэрлэх чадварыг мартаж болохгүй. Нэг сервер доголдож, VM-г HA ашиглан дахин ачаалах үед зарим машинууд Swap руу орох нь тааламжгүй байдаг.
- Өндөр нягтаршилтай дэд бүтцэд хост санах ойн талаас илүү хувийг багтаасан VM-үүдийг үүсгэхийг БҮҮ оролдоорой. Энэ нь дахин DRS-д виртуал машинуудыг кластер серверүүдээр ямар ч асуудалгүйгээр түгээхэд тусална. Энэ дүрэм нь мэдээжийн хэрэг бүх нийтийн биш юм :).
- Хост санах ойн ашиглалтын дохиололыг ажиглаарай.
- VM-д VMware Tools суулгахаа бүү мартаарай, Ballooning-ийг унтрааж болохгүй.
- Inter-VM TPS-ийг идэвхжүүлж, VDI болон туршилтын орчинд том хуудаснуудыг идэвхгүй болгох талаар бодож үзээрэй.
- Хэрэв VM нь гүйцэтгэлийн асуудалтай тулгарвал алсын NUMA зангилааны санах ойг ашиглаж байгаа эсэхийг шалгана уу.
- VM-ээ Swap-аас аль болох хурдан гарга! Бусад зүйлсийн дотор, хэрэв VM нь Swap-д байгаа бол тодорхой шалтгааны улмаас хадгалах систем нь хохирдог.
Энэ бол миний хувьд RAM-ийн тухай юм. Дэлгэрэнгүйг нь ухах хүсэлтэй хүмүүст зориулж доорх нийтлэлийг оруулав. Дараагийн өгүүллийг storadzh-д зориулах болно.
Ашигтай холбоосууд
Эх сурвалж: www.habr.com