هن آرٽيڪل ۾ اسين ڳالهائينداسين بي ترتيب رسائي ميموري (RAM) ڪارڪردگي ڳڻپيندڙ vSphere ۾.
اهو لڳي ٿو ته ميموري سان هر شيء پروسيسر جي ڀيٽ ۾ وڌيڪ واضح آهي: جيڪڏهن ڪارڪردگي مسئلا VM تي پيدا ٿئي ٿي، انهن کي نوٽيس ڪرڻ ڏکيو ناهي. پر جيڪڏهن اهي ظاهر ٿين ٿا، اهو انهن سان معاملو ڪرڻ تمام گهڻو ڏکيو آهي. پر پهرين شيون پهرين.
نظريي جو ھڪڙو
ورچوئل مشينن جي رام ان سرور جي ميموري مان ورتي ويندي آهي جنهن تي VM هلندا آهن. اهو بلڪل واضح آهي :). جيڪڏهن سرور جي رام هر ڪنهن لاءِ ڪافي نه آهي، ESXi ميموري جي بحالي واري ٽيڪنالاجي کي استعمال ڪرڻ شروع ڪري ٿو. ٻي صورت ۾، VM آپريٽنگ سسٽم رام رسائي جي غلطين سان حادثو ڪري سگهندا.
ESXi فيصلو ڪري ٿو ته ڪهڙيون ٽيڪنالاجيون استعمال ڪيون وڃن رام لوڊ جي لحاظ سان:
ياداشت جي حالت
سرحد
عمل
هاء
400% منٽ مفت
مٿين حد تائين پهچڻ کان پوءِ، وڏا ياداشت وارا صفحا ورهائجي ويندا آهن ننڍن ۾ (TPS هلندي آهي معياري موڊ ۾).
پڌري
100% منٽ مفت
وڏن ياداشتن جا صفحا ننڍڙن صفحن ۾ ورهايل آهن، TPS مجبور آهي.
نرم
64% منٽ مفت
TPS + بالون
سخت
32% منٽ مفت
TPS + Compress + Swap
گھٽ
16% منٽ مفت
ڪمپريس + ادل + بلاڪ
minFree ھائپر وائيزر کي هلائڻ لاءِ گھربل رام آھي.
ESXi 4.1 تائين شامل، minFree کي ڊفالٽ طور مقرر ڪيو ويو - 6% سرور جي RAM (فيصد ESXi تي Mem.MinFreePct آپشن ذريعي تبديل ٿي سگھي ٿو). پوئين ورزن ۾، سرورز تي ميموري جي واڌ جي ڪري، minFree کي ميزبان جي ميموري جي مقدار جي بنياد تي ڳڻيو وڃي ٿو، نه ڪي مقرر ڪيل فيصد قدر جي حساب سان.
minFree قدر (ڊفالٽ) حساب ڪيو ويو آھي ھيٺ ڏنل آھي:
منٽ فري لاءِ رکيل ياداشت جو سيڪڙو
ياداشت جي حد
6%
0-4 جي بي
4%
4-12 جي بي
2%
12-28 جي بي
1%
باقي ياداشت
مثال طور، هڪ سرور لاءِ 128 GB جي رام سان، MinFree قدر هن ريت هوندي:
منٽ فري = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
اصل قدر مختلف ٿي سگھي ٿو ٻه سو ايم بي، سرور ۽ رام جي لحاظ کان.
منٽ فري لاءِ رکيل ياداشت جو سيڪڙو
ياداشت جي حد
128 GB جي قيمت
6%
0-4 جي بي
245,76 MB
4%
4-12 جي بي
327,68 MB
2%
12-28 جي بي
327,68 MB
1%
باقي ياداشت (100 GB)
1024 MB
عام طور تي، پيداواري اسٽينڊ لاء، صرف اعلي رياست کي عام سمجهي سگهجي ٿو. ٽيسٽ ۽ ڊولپمينٽ بينچن لاءِ، صاف/نرم رياستون قابل قبول ٿي سگھن ٿيون. جيڪڏهن ميزبان تي ريم 64٪ MinFree کان گهٽ آهي، ته پوءِ ان تي هلندڙ وي ايمز ضرور ڪارڪردگي جي مسئلن جو شڪار آهن.
هر رياست ۾، ڪجهه ياداشت جي بحالي واري ٽيڪنڪ استعمال ٿينديون آهن، TPS کان شروع ٿيندي، جن جو عملي طور تي VM ڪارڪردگي تي ڪو به اثر ناهي، سوپنگ تائين. مان توهان کي انهن بابت وڌيڪ ٻڌائيندس.
شفاف صفحو شيئرنگ (TPS). TPS آهي، تقريبن ڳالهائڻ، سرور تي ورچوئل مشينن جي رام صفحن جو نقل.
ESXi هڪجهڙي ورچوئل مشين RAM صفحن کي ڳولهي ٿو ۽ صفحن جي هيش رقم کي ڳڻڻ ۽ موازنہ ڪندي، ۽ نقل ٿيل صفحن کي هٽائي ٿو، انهن کي سرور جي جسماني ياداشت ۾ ساڳئي صفحي جي حوالي سان تبديل ڪري ٿو. نتيجي طور، جسماني ياداشت جو استعمال گھٽجي ويو آهي ۽ ڪجهه ياداشت جي اوور سبسڪرپشن حاصل ڪري سگهجي ٿي عملي طور تي ڪارڪردگي جي اثر سان.
هي ميکانيزم صرف 4 KB سائيز جي ميموري صفحن لاءِ ڪم ڪري ٿو (ننڍا صفحا). هائپر وائزر 2 MB سائيز (وڏا صفحا) جي صفحن کي ڊاهڻ جي ڪوشش به نه ڪندو آهي: هن سائيز جا هڪجهڙا صفحا ڳولڻ جو موقعو وڏو ناهي.
ڊفالٽ طور، ESXi ميموري کي وڏن صفحن ڏانهن مختص ڪري ٿو. وڏن صفحن کي ننڍن صفحن ۾ ورهائڻ شروع ٿئي ٿو جڏهن اعلي رياست جي حد تائين پهچي وڃي ٿي ۽ مجبور ڪيو وڃي ٿو جڏهن صاف رياست پهچي وڃي (ڏسو هائپر ويزر اسٽيٽ ٽيبل).
جيڪڏھن توھان چاھيو ٿا TPS ڪم ڪرڻ شروع ڪري بغير ھوسٽ جي ريم جي پوري ٿيڻ جو انتظار ڪري، توھان کي قيمت مقرر ڪرڻ جي ضرورت آھي Advanced Options ESXi ۾ "Mem.AllocGuestLargePage" 0 تائين (ڊفالٽ 1). پوءِ ورچوئل مشينن لاءِ وڏي ميموري صفحن جو مختص بند ڪيو ويندو.
ڊسمبر 2014 کان وٺي، سڀني ESXi رليزز ۾، VMs جي وچ ۾ TPS ڊفالٽ طور تي بند ٿيل آهي، جيئن ته هڪ ڪمزوري ملي ٿي ته نظرياتي طور تي هڪ VM کي ٻئي VM جي رام تائين رسائي جي اجازت ڏئي ٿي. تفصيل هتي. مون کي TPS جي ڪمزورين کي استعمال ڪرڻ جي عملي عمل جي باري ۾ معلومات نه ملي آهي.
TPS پاليسي ترقي يافته اختيار ذريعي ڪنٽرول ڪئي وئي آهي "Mem.ShareForceSalting" ESXi تي:
0 - Inter-VM TPS. TPS مختلف VMs جي صفحن لاءِ ڪم ڪري ٿو؛
1 - VMs لاءِ TPS ساڳيا “sched.mem.pshare.salt” قدر سان VMX ۾؛
2 (ڊفالٽ) - Intra-VM TPS. TPS هڪ VM اندر صفحن لاء ڪم ڪري ٿو.
اهو يقيني طور تي سمجھ ۾ اچي ٿو ته وڏن صفحن کي غير فعال ڪرڻ ۽ ٽيسٽ بينچ تي Inter-VM TPS کي فعال ڪرڻ. اهو پڻ استعمال ڪري سگهجي ٿو اسٽينڊ لاءِ وڏي تعداد ۾ ساڳي وي ايم سان. مثال طور، وي ڊي آئي سان اسٽينڊ تي، جسماني ياداشت ۾ بچت ڏهن سيڪڙو تائين پهچي سگهي ٿي.
ميموري بالوننگ. بلوننگ هاڻي VM آپريٽنگ سسٽم لاءِ اهڙي بي ضرر ۽ شفاف ٽيڪنڪ ناهي جيئن TPS. پر جيڪڏهن صحيح طريقي سان استعمال ڪيو وڃي، توهان زندگي گذاري سگهو ٿا ۽ بالوننگ سان پڻ ڪم ڪري سگهو ٿا.
Vmware اوزار سان گڏ، هڪ خاص ڊرائيور سڏيو ويندو آهي بالون ڊرائيور (اڪا vmmemctl) VM تي نصب ٿيل آهي. جڏهن هائپر وائيزر جسماني ياداشت کان ٻاهر هلڻ شروع ڪري ٿو ۽ نرم حالت ۾ داخل ٿئي ٿو، ESXi VM کان پڇي ٿو ته هن بالون ڊرائيور ذريعي غير استعمال ٿيل رام کي ٻيهر حاصل ڪرڻ لاء. ڊرائيور، موڙ ۾، آپريٽنگ سسٽم جي سطح تي ڪم ڪري ٿو ۽ ان کان مفت ياداشت جي درخواست ڪري ٿو. هائپرائزر ڏسي ٿو ته جسماني ياداشت جا ڪهڙا صفحا بلون ڊرائيور قبضو ڪيا آهن، ورچوئل مشين مان ميموري وٺي ٿو ۽ ان کي ميزبان ڏانهن واپس ڪري ٿو. او ايس جي آپريشن سان ڪو به مسئلو ناهي، ڇو ته او ايس جي سطح تي ميموري بالون ڊرائيور جي قبضي ۾ آهي. ڊفالٽ طور، بالون ڊرائيور وٺي سگھي ٿو 65٪ تائين VM ياداشت جي.
جيڪڏهن VMware اوزار VM تي نصب نه آهن يا بالوننگ بند ٿيل آهي (مان ان جي سفارش نه ٿو ڪريان، پر اتي موجود آهي. :)، هائپرائزر فوري طور تي ميموري کي هٽائڻ لاء وڌيڪ سخت ٽيڪنالاجي ڏانهن تبديل ڪري ٿو. نتيجو: پڪ ڪريو ته VMware اوزار VM تي آهن.
بلون ڊرائيور جو آپريشن OS کان VMware اوزار ذريعي چيڪ ڪري سگھجي ٿو.
ميموري ڪمپريشن. هي ٽيڪنڪ استعمال ڪيو ويندو آهي جڏهن ESXi هارڊ اسٽيٽ تي پهچي ٿو. جيئن ته نالو مشورو ڏئي ٿو، ESXi ڪوشش ڪري ٿو 4KB صفحي جي رام کي 2KB ۾ دٻائڻ، ان ڪري سرور جي جسماني ياداشت ۾ ڪجهه جاءِ خالي ڪري ٿي. هي ٽيڪنڪ خاص طور تي VM RAM صفحن جي مواد تائين پهچ جي وقت کي وڌائي ٿي، ڇاڪاڻ ته صفحي کي پهريان کان ڊمپپريس ڪيو وڃي. ڪڏهن ڪڏهن نه سڀئي صفحا دٻجي سگھجن ٿا ۽ عمل پاڻ کي ڪجهه وقت وٺندو آهي. تنهن ڪري، هن ٽيڪنڪ عملي طور تي تمام مؤثر نه آهي.
ميموري مٽائڻ. ميموري ڪمپريشن جي هڪ مختصر مرحلي کان پوءِ، ESXi لڳ ڀڳ ناگزير طور تي (جيڪڏهن VMs ٻين ميزبانن ڏانهن منتقل نه ٿيا آهن يا بند نه ڪيا ويا آهن) سوائپنگ ڏانهن سوئچ ڪندو آهي. ۽ جيڪڏهن تمام ٿوري ميموري رهجي وئي آهي (گهٽ رياست)، ته پوءِ هائپرائزر به بند ڪري ٿو ميموري صفحن کي مختص ڪرڻ VM ڏانهن، جيڪو VM جي مهمان او ايس ۾ مسئلا پيدا ڪري سگهي ٿو.
اهڙيءَ طرح ادل بدلائڻ جو ڪم آهي. جڏهن توهان هڪ ورچوئل مشين آن ڪندا آهيو، ان لاءِ .vswp ايڪسٽينشن سان هڪ فائل ٺاهي ويندي آهي. اهو سائيز ۾ وي ايم جي غير محفوظ ٿيل رام جي برابر آهي: هي ترتيب ڏنل ۽ محفوظ ڪيل ياداشت جي وچ ۾ فرق آهي. جڏهن ادل بدلي رهيو آهي، ESXi ورچوئل مشين ميموري صفحن کي هن فائل ۾ تبديل ڪري ٿو ۽ سرور جي جسماني ميموري جي بدران ان سان ڪم ڪرڻ شروع ڪري ٿو. يقينا، اهڙي "رام" ياداشت حقيقي ياداشت جي ڀيٽ ۾ سست رفتار جي ڪيترن ئي حڪمن تي آهي، جيتوڻيڪ .vswp تيز اسٽوريج تي آهي.
بالوننگ جي برعڪس، جڏهن اڻ استعمال ٿيل صفحا هڪ VM مان کنيا ويندا آهن، انهن صفحن کي تبديل ڪرڻ سان جيڪي فعال طور تي OS پاران استعمال ڪيا ويندا آهن يا VM اندر ايپليڪيشنون ڊسڪ ڏانهن منتقل ٿي سگهن ٿيون. نتيجي طور، VM جي ڪارڪردگي منجمد ٿيڻ جي نقطي تي اچي ٿو. VM رسمي طور تي ڪم ڪري رهيو آهي ۽ گهٽ ۾ گهٽ ان کي او ايس مان صحيح طور تي بند ڪري سگهجي ٿو. جيڪڏهن توهان صبر ڪيو 😉
جيڪڏهن VMs ادل بدلجي ويا آهن، اها هڪ هنگامي صورتحال آهي جيڪا ممڪن هجي ته بهترين کان بچي وڃي.
بنيادي ورچوئل مشين ميموري ڪارڪردگي ڪائونٽر
تنهنڪري اسان کي اصل شيء ملي. VM جي ياداشت جي حالت کي مانيٽر ڪرڻ لاء، هيٺيان ڳڻپيندڙ آهن:
سرگرم - ڏيکاري ٿو RAM جي مقدار (KB) جيڪا VM اڳئين ماپ جي مدت ۾ رسائي ڪئي.
استعمال - ساڳيو ئي فعال، پر VM جي ترتيب ڏنل رام جي سيڪڙو جي طور تي. هيٺ ڏنل فارمولا استعمال ڪندي حساب ڪيو ويو: فعال ÷ ورچوئل مشين ترتيب ڏنل ميموري سائيز.
اعلي استعمال ۽ فعال، ترتيب سان، هميشه VM ڪارڪردگي جي مسئلن جو اشارو نه آهن. جيڪڏهن VM جارحيت سان ميموري استعمال ڪري رهيو آهي (گهٽ ۾ گهٽ ان تائين رسائي)، هن جو مطلب اهو ناهي ته ڪافي ياداشت نه آهي. بلڪه، اهو ڏسڻ جو هڪ سبب آهي ته او ايس ۾ ڇا ٿي رهيو آهي.
VMs لاءِ ياداشت جي استعمال لاءِ معياري الارم آھي:
شيئر - VM RAM جو مقدار TPS استعمال ڪندي ڪٽايو ويو (VM اندر يا VMs جي وچ ۾).
عطا ڪيل - ميزبان جسماني ياداشت جو مقدار (KB) جيڪو مختص ڪيو ويو VM ڏانهن. شيئر کي فعال ڪري ٿو.
واڌو (منظور - حصيداري) - جسماني ياداشت جي مقدار (KB) جيڪا VM ميزبان کان استعمال ڪري ٿي. حصيداري شامل نه آهي.
جيڪڏهن VM ميموري جو حصو نه ڏنو ويو آهي ميزبان جي جسماني ياداشت مان، پر هڪ ادل واري فائل مان، يا ياداشت VM مان بيلون ڊرائيور ذريعي ورتي وئي آهي، اها رقم گرانٽ ۽ استعمال ۾ نه ورتي وئي آهي.
هاء گرانٽ ۽ استعمال ٿيل قدر مڪمل طور تي عام آهن. آپريٽنگ سسٽم تيزيء سان هائپرائزر کان ياداشت وٺندو آهي ۽ ان کي واپس نه ڏيندو آهي. وقت سان گڏ، فعال طور تي هلندڙ VM ۾، انهن ڳڻپيندڙن جا قدر ترتيب ڏنل ميموري جي مقدار تائين پهچندا آهن، ۽ اتي ئي رهندا آهن.
ٻُڙي - VM RAM جو مقدار (KB)، جنھن ۾ صفر شامل آھن. اهڙي ياداشت کي هائپرائزر طرفان مفت سمجهيو ويندو آهي ۽ ٻين ورچوئل مشينن کي ڏئي سگهجي ٿو. مهمان OS کان پوءِ ڪجهه لکيو ويو آهي ميموري کي صفر ڪرڻ لاءِ، اهو استعمال ۾ وڃي ٿو ۽ واپس نه ٿو اچي.
محفوظ ڪيل مٿي - VM RAM جو مقدار، (KB) VM آپريشن لاءِ هائپرائزر طرفان محفوظ ڪيو ويو آهي. هي هڪ ننڍڙي رقم آهي، پر اهو ميزبان تي دستياب هجڻ گهرجي، ٻي صورت ۾ VM شروع نه ٿيندو.
غبرا - بالون ڊرائيور استعمال ڪندي VM مان هٽايو ويو رام (KB) جو مقدار.
سازش - رام جو مقدار (KB) جيڪو دٻايو ويو.
بدليل - رام جو مقدار (KB)، جيڪو، سرور تي جسماني ياداشت جي کوٽ جي ڪري، ڊسڪ ڏانهن منتقل ڪيو ويو.
بلون ۽ ٻين ياداشت جي بحالي واري ٽيڪنڪ شمار ڪندڙ صفر آهن.
اھو اھو آھي جيڪو گراف وانگر ڏسڻ ۾ اچي ٿو ميموري ڳڻپيندڙن سان عام طور تي ڪم ڪندڙ VM جي 150 GB ريم سان.
هيٺ ڏنل گراف ۾، VM واضح مسئلا آهن. هيٺ ڏنل گراف توهان ڏسي سگهو ٿا ته هن VM لاء رام سان ڪم ڪرڻ لاء سڀ بيان ڪيل ٽيڪنالاجي استعمال ڪيا ويا. هن VM لاءِ بالون استعمال ٿيل کان تمام وڏو آهي. حقيقت ۾، VM زنده کان وڌيڪ مئل آهي.
ESXTOP
جيئن ته سي پي يو سان، جيڪڏهن اسان چاهيون ٿا ته جلدي طور تي ميزبان تي صورتحال جو جائزو وٺو، انهي سان گڏ ان جي متحرڪ 2 سيڪنڊن جي وقفي سان، اسان کي استعمال ڪرڻ گهرجي ESXTOP.
ESXTOP ميموري اسڪرين کي "m" ڪيئي سان سڏيو ويندو آهي ۽ هن وانگر ڏسڻ ۾ اچي ٿو (فيلز B، D، H، J، K، L، O منتخب ٿيل):
هيٺ ڏنل پيراگراف اسان لاء دلچسپي هوندي.
ميم overcommit avg - 1، 5 ۽ 15 منٽن لاءِ ميزبان تي ميموري اوور سبسڪرپشن جو سراسري قدر. جيڪڏهن اهو صفر کان مٿي آهي، ته اهو هڪ سبب آهي ته ڇا ٿي رهيو آهي، پر هميشه مسئلن جو اشارو نه آهي.
قطارن ۾ PMEM/MB и VMKMEM/MB - سرور جي جسماني ياداشت بابت معلومات ۽ VMkernel وٽ موجود ياداشت. هتي دلچسپ شين مان توهان ڏسي سگهو ٿا minfree قدر (MB ۾)، ميزبان رياست ياداشت ۾ (اسان جي صورت ۾، اعلي).
قطار ۾ NUMA/MB توھان NUMA نوڊس (ساڪيٽ) ۾ رام جي ورڇ ڏسي سگھو ٿا. هن مثال ۾، ورڇ اڻ برابر آهي، جيڪو اصول ۾ تمام سٺو ناهي.
ميموري جي بحالي واري ٽيڪنالاجي لاءِ هيٺ ڏنل عام سرور جا انگ اکر آهن:
PSHARE/MB - اهي آهن TPS جا انگ اکر؛
SWAP/MB - استعمال جي انگن اکرن کي تبديل ڪريو؛
ZIP/MB - ياداشت واري صفحي جي ڪمپريشن جا انگ اکر؛
MEMCTL/MB - بالون ڊرائيور استعمال جا انگ اکر.
انفرادي VMs لاءِ، اسان کي هيٺين معلومات ۾ دلچسپي ٿي سگھي ٿي. مون VM جا نالا لڪايا ته جيئن سامعين کي پريشان نه ٿئي :). جيڪڏهن ESXTOP ميٽرڪ vSphere ۾ ڪائونٽر سان ملندڙ جلندڙ آهي، مان لاڳاپيل ڪائونٽر مهيا ڪندس.
ايم ايم ايسز - VM (MB) تي ترتيب ڏنل ياداشت جي مقدار.
MEMSZ = GRANT + MCTLSZ + SWCUR + اڻ ڇهيو.
مدد - MB ۾ ڏني وئي.
TCHD - MByte ۾ فعال.
ايم سي ٽي ايل؟ - ڇا بلون ڊرائيور VM تي نصب ٿيل آهي.
MCTLSZ - بلون کان ايم بي.
MCTLGT - رام جو مقدار (MBytes) جنهن کي ESXi بالون ڊرائيور (Memctl ٽارگيٽ) ذريعي VM مان هٽائڻ چاهي ٿو.
MCTLMAX - رام جي وڌ ۾ وڌ مقدار (MBytes) جيڪا ESXi بيلون ڊرائيور ذريعي VM مان هٽائي سگھي ٿي.
SWCUR - RAM جو موجوده مقدار (MBytes) Swap فائل مان VM کي مختص ڪيو ويو.
S.W.G.T. - رام جو مقدار (MBytes) جيڪو ESXi ڏيڻ چاهي ٿو VM کي Swap فائل (Swap Target) مان.
توھان ESXTOP ذريعي VM جي NUMA ٽوپولوجي بابت وڌيڪ تفصيلي ڄاڻ پڻ ڏسي سگھو ٿا. هن کي ڪرڻ لاءِ، منتخب ڪريو فيلڊس D، G:
اين ايڇ اين - NUMA نوڊس جنهن تي VM واقع آهي. هتي توهان فوري طور تي وڏي وي ايم کي نوٽيس ڪري سگهو ٿا، جيڪي هڪ NUMA نوڊ تي نه هجن.
NRMEM - ڪيتري ميگا بائيٽ ميموري VM ريموٽ NUMA نوڊ کان وٺي ٿي.
اين ايل ايم ايم - ڪيتري ميگا بائيٽ ياداشت جي VM مقامي NUMA نوڊ کان وٺي ٿي.
ن% ايل - مقامي NUMA نوڊ تي VM ياداشت جو سيڪڙو (جيڪڏهن 80٪ کان گهٽ، ڪارڪردگي جا مسئلا پيدا ٿي سگهن ٿيون).
هائپرائزر تي ياداشت
جيڪڏهن هائپر ويزر لاءِ سي پي يو ڳڻپيوڪر عام طور تي خاص دلچسپي نه هوندا آهن، پوءِ ياداشت سان صورتحال ان جي ابتڙ آهي. VM تي اعلي ميموري استعمال هميشه ڪارڪردگي جي مسئلي کي ظاهر نٿو ڪري، پر هڪ هائپر ويزر تي اعلي ميموري استعمال ميموري مئنيجمينٽ ٽيڪنڪ کي متحرڪ ڪري ٿو ۽ VM ڪارڪردگي سان مسئلا پيدا ڪري ٿو. توھان کي ھوسٽ ميموري جي استعمال جي الارم جي نگراني ڪرڻ جي ضرورت آھي ۽ VMs کي ادل ۾ اچڻ کان روڪڻ جي ضرورت آھي.
مٽائڻ
جيڪڏهن هڪ VM ادل ۾ پکڙيل آهي، ان جي ڪارڪردگي تمام گهٽجي ويندي آهي. بلوننگ ۽ ڪمپريشن جا نشان جلدي غائب ٿي ويندا آهن جڏهن ميزبان تي مفت ريم ظاهر ٿئي ٿي، پر ورچوئل مشين سويپ کان سرور جي رام ڏانهن موٽڻ جي جلدي ۾ ناهي.
ESXi 6.0 کان اڳ، Swap مان VM کي هٽائڻ جو واحد قابل اعتماد ۽ تيز رستو ريبوٽ ڪرڻ هو (وڌيڪ واضح طور تي، بند ڪريو / ڪنٽينر تي). ESXi 6.0 سان شروع ٿئي ٿو، جيتوڻيڪ مڪمل طور تي سرڪاري نه آهي، هڪ ڪم ڪندڙ ۽ قابل اعتماد طريقو هڪ VM کي هٽائڻ لاء Swap مان ظاهر ٿيو آهي. هڪ ڪانفرنس ۾، مان هڪ VMware انجنيئر سان ڳالهائڻ جي قابل ٿي ويو CPU شيڊولر جي ذميوار. هن تصديق ڪئي ته طريقو ڪافي ڪم ڪندڙ ۽ محفوظ آهي. اسان جي تجربي ۾، ان سان ڪو به مسئلو نه هو.
Swap مان هڪ VM کي هٽائڻ لاء حقيقي حڪم ڊنڪن ايپنگ. مان تفصيلي بيان نه ورجائيندس، مان صرف ان جي استعمال جو هڪ مثال ڏيندس. جئين توهان اسڪرين شاٽ ۾ ڏسي سگهو ٿا، ڪجهه وقت کان پوء مخصوص حڪم تي عمل ڪرڻ کان پوء، وي ايم تي ادل غائب ٿي.
ESXi تي رام جي انتظام لاءِ صلاحون
آخرڪار، هتي ڪجھ تجاويز آهن جيڪي توهان جي مدد ڪندي رام جي ڪري VM ڪارڪردگي سان مسئلن کان بچڻ ۾:
- پيداواري ڪلستر ۾ رام جي اوور سبسڪرپشن کان پاسو ڪريو. اهو مشورو ڏنو ويو آهي ته ڪلستر ۾ هميشه ~ 20-30٪ مفت ميموري هجي ته جيئن DRS (۽ منتظم) کي ڪمرو ڪرڻ لاءِ ڪمرو هجي ۽ VMs لڏپلاڻ دوران ادل نه وڃن. انهي سان گڏ، غلطي رواداري لاء مارجن جي باري ۾ نه وساريو. اهو ناپسنديده آهي، جڏهن هڪ سرور ناڪام ٿئي ٿو ۽ VM HA استعمال ڪندي ريبوٽ ڪيو ويو آهي، ڪجهه مشينون پڻ ادل ڏانهن وينديون آهن.
- انتهائي مضبوط انفراسٽرڪچر ۾، ڪوشش نه ڪريو VMs ٺاهڻ جي ميموري سان اڌ ميزبان ياداشت کان وڌيڪ. هي وري ڊي آر ايس جي مدد ڪندو ورچوئل مشينن کي ڪلسٽر سرورز ۾ بغير ڪنهن پريشاني جي. هي قاعدو، يقينا، آفاقي نه آهي :).
- هوسٽ ميموري استعمال الارم لاءِ ڏسو.
- VM تي VMware اوزار انسٽال ڪرڻ نه وساريو ۽ بالوننگ کي بند نه ڪريو.
- غور ڪريو Inter-VM TPS کي فعال ڪرڻ ۽ VDI ۽ ٽيسٽ ماحول ۾ وڏن صفحن کي غير فعال ڪرڻ.
- جيڪڏهن VM ڪارڪردگي جي مسئلن جو تجربو ڪري رهيو آهي، چيڪ ڪريو ته ڇا اهو ريموٽ NUMA نوڊ کان ميموري استعمال ڪري رهيو آهي.
- جيترو جلدي ٿي سگهي مٽائي مان VMs کي هٽايو! ٻين شين جي وچ ۾، جيڪڏهن VM ادل ۾ آهي، اسٽوريج سسٽم واضح سببن لاء برداشت ڪري ٿو.
اهو سڀ ڪجهه مون لاءِ رام بابت آهي. هيٺ ڏنل مضمونن سان لاڳاپيل آهن انهن لاءِ جيڪي اونهي وڃڻ چاهين ٿا. ايندڙ مضمون storage لاء وقف ڪيو ويندو.
ڪارآمد لنڪ
جو ذريعو: www.habr.com