جيڪڏهن توهان VMware vSphere (يا ڪنهن ٻئي ٽيڪنالاجي اسٽيڪ) جي بنياد تي هڪ ورچوئل انفراسٽرڪچر جو انتظام ڪريو ٿا، ته پوءِ توهان شايد اڪثر صارفين کان شڪايتون ٻڌي رهيا آهيو: "مجازي مشين سست آهي!". مضمونن جي هن سلسلي ۾، مان ڪارڪردگي جي ماپن جو تجزيو ڪندس ۽ توهان کي ٻڌايان ٿو ته ڇا ۽ ڇو "سست ٿي وڃي ٿو" ۽ ڪيئن پڪ ڪجي ته اهو "سست" نه ٿئي.
مان ورچوئل مشين جي ڪارڪردگي جي هيٺين حصن تي غور ڪندس:
- سي پي يو ،
- فريم ،
- ڊسڪ،
- نيٽورڪ
مان CPU سان شروع ڪندس.
ڪارڪردگي جي تجزيي لاء اسان کي ضرورت آهي:
- vCenter ڪارڪردگي شمار ڪندڙ - ڪارڪردگي ڳڻپيندڙ، گرافس جن مان ڏسي سگھجي ٿو vSphere ڪلائنٽ ذريعي. انهن ڳڻپيندڙن تي معلومات ڪلائنٽ جي ڪنهن به ورزن ۾ موجود آهي (C# ۾ "ٿلهي" ڪلائنٽ، Flex ۾ ويب ڪلائنٽ، ۽ HTML5 ۾ ويب ڪلائنٽ). انهن مضمونن ۾، اسان استعمال ڪنداسين اسڪرين شاٽ سي # ڪلائنٽ مان، صرف ان ڪري ته اهي ننڍي ۾ بهتر نظر اچن ٿا :)
- ESXTOP هڪ افاديت آهي جيڪا ESXi ڪمانڊ لائن کان هلندي آهي. ان جي مدد سان، توھان حاصل ڪري سگھوٿا پرفارمنس ڳڻپيوڪر جا قدر حقيقي وقت ۾ يا انھن قدرن کي ھڪ خاص مدت لاءِ اپلوڊ ڪري سگھوٿا .csv فائل ۾ وڌيڪ تجزيو لاءِ. اڳيون، مان توهان کي هن اوزار بابت وڌيڪ ٻڌائيندس ۽ مهيا ڪندس ڪجهه مفيد لنڪ دستاويزن ۽ مضمونن تي مضمونن لاءِ.
نظريي جو ھڪڙو
ESXi ۾، هڪ الڳ عمل هر وي سي پي يو (ورچوئل مشين ڪنيل) جي آپريشن لاءِ ذميوار آهي - دنيا ۾ VMware اصطلاحن ۾. اتي پڻ خدمت جا عمل آھن، پر وي ايم ڪارڪردگي جي تجزيو جي نقطي نظر کان، اھي گھٽ دلچسپ آھن.
ESXi ۾ هڪ عمل چار رياستن مان هڪ ٿي سگهي ٿو:
- هل عمل ڪجهه مفيد ڪم ڪري رهيو آهي.
- انتظار - اهو عمل ڪو به ڪم نٿو ڪري (بيڪار) يا ان پٽ / آئوٽ جو انتظار ڪري ٿو.
- ڪاسٽپ - هڪ رياست جيڪا ملٽي ڪور ورچوئل مشينن ۾ ٿئي ٿي. اهو تڏهن ٿئي ٿو جڏهن هائپر ويزر جو سي پي يو شيڊولر (ESXi CPU شيڊيولر) هڪ ئي وقت سرور جي جسماني ڪور تي هلائڻ لاءِ سڀني فعال ورچوئل مشين ڪور کي شيڊول نٿو ڪري سگهي. جسماني دنيا ۾، سڀئي پروسيسر ڪور متوازي ۾ هلن ٿا، VM اندر مهمان او ايس ساڳئي رويي جي توقع رکي ٿو، تنهنڪري هائپرائزر کي وي ايم ڪور کي سست ڪرڻو پوندو، جنهن کي چڪر کي تيزيء سان ختم ڪرڻ جو موقعو آهي. ESXi جي جديد ورزن ۾، سي پي يو شيڊولر هڪ ميکانيزم استعمال ڪري ٿو جنهن کي آرام سان ڪو شيڊولنگ سڏيو ويندو آهي: هائپر وائيزر "تيز ترين" ۽ "سست" ورچوئل مشين ڪور (اسڪيو) جي وچ ۾ خال کي ڳڻائي ٿو. جيڪڏهن خال هڪ خاص حد کان وڌي وڃي ٿي، "تيز" ڪور ڪاسٽپ اسٽيٽ ۾ داخل ٿئي ٿو. جيڪڏهن VM ڪور هن رياست ۾ گهڻو وقت گذاريندا آهن، اهو ڪارڪردگي مسئلن جو سبب بڻجي سگهي ٿو.
- تيار - اهو عمل هن حالت ۾ داخل ٿئي ٿو جڏهن هائپرائزر ان جي عمل لاءِ وسيلن کي مختص ڪرڻ جي قابل ناهي. اعلي تيار ڪيل قيمتون شايد VM ڪارڪردگي مسئلن جو سبب بڻجن ٿيون.
مکيه VM CPU ڪارڪردگي شمار ڪندڙ
سي پي يو استعمال،٪. مخصوص مدت لاءِ سي پي يو جي استعمال جو سيڪڙو ڏيکاري ٿو.
تجزيو ڪيئن ڪجي؟ جيڪڏهن VM مسلسل 90٪ تي سي پي يو استعمال ڪري ٿو يا 100٪ تائين چوٽيون آهن، پوء اسان وٽ هڪ مسئلو آهي. مسئلا نه رڳو VM اندر ايپليڪيشن جي "سست" آپريشن ۾، پر نيٽ ورڪ تي VM جي ناقابل رسائي ۾ پڻ بيان ڪري سگھجن ٿيون. جيڪڏهن مانيٽرنگ سسٽم ڏيکاري ٿو ته VM وقتي طور تي بند ٿئي ٿي، سي پي يو جي استعمال جي گراف تي چوٽي تي ڌيان ڏيو.
اتي ھڪڙو معياري الارم آھي جيڪو ڏيکاري ٿو سي پي يو لوڊ مجازي مشين جي:
آئون ڇا ڪريان؟ جيڪڏهن VM ۾ مسلسل CPU استعمال بند ٿي رهيو آهي، ته پوءِ توهان سوچي سگهو ٿا vCPUs جو تعداد وڌائڻ بابت (بدقسمتي سان، اهو هميشه مدد نه ڪندو آهي) يا VM کي وڌيڪ موثر پروسيسرز سان سرور ڏانهن منتقل ڪرڻ.
Mhz ۾ CPU استعمال
vCenter تي گرافس ۾، % ۾ استعمال صرف سڄي ورچوئل مشين لاءِ ڏسي سگھجي ٿو، انفرادي ڪور لاءِ ڪي به گراف نه آھن (Extop ۾، cores لاءِ % ۾ قدر آھن). هر ڪور لاء، توهان MHz ۾ استعمال ڏسي سگهو ٿا.
تجزيو ڪيئن ڪجي؟ اهو ٿئي ٿو ته هڪ ايپليڪيشن ملٽي-ڪور آرڪيٽيڪچر لاءِ بهتر نه ڪئي وئي آهي: اهو 100٪ تي صرف هڪ ڪور استعمال ڪري ٿو، ۽ باقي لوڊ کان سواءِ بيڪار آهن. مثال طور، ڊفالٽ بيڪ اپ سيٽنگن سان، MS SQL صرف هڪ ڪور تي عمل شروع ڪري ٿو. نتيجي طور، بيڪ اپ سست نه ٿئي ڇاڪاڻ ته ڊسڪ جي سست رفتار جي ڪري (اهو آهي جيڪو صارف جي شروعات ۾ شڪايت ڪيو آهي)، پر ڇاڪاڻ ته پروسيسر کي منهن نه ٿو ڏئي سگهجي. مسئلو پيٽرولر کي تبديل ڪندي حل ڪيو ويو: بيڪ اپ ڪيترن ئي فائلن ۾ متوازي ۾ هلڻ شروع ڪيو (ترتيب، ڪيترن ئي عملن ۾).
ڪور جي اڻ برابري لوڊ ڪرڻ جو هڪ مثال.
اتي پڻ هڪ صورتحال آهي (جيئن مٿي ڏنل گراف ۾) جڏهن ڪور اڻ برابري سان لوڊ ڪيا ويا آهن ۽ انهن مان ڪجهه 100٪ جي چوٽي آهي. جيئن صرف هڪ ڪور لوڊ ڪرڻ سان، سي پي يو استعمال جو الارم ڪم نه ڪندو (اهو سڀ وي ايم تي آهي)، پر ڪارڪردگي جا مسئلا هوندا.
آئون ڇا ڪريان؟ جيڪڏهن ورچوئل مشين ۾ سافٽ ويئر اڻ برابري سان ڪور کي لوڊ ڪري ٿو (صرف هڪ ڪور يا ڪور جو حصو استعمال ڪري ٿو)، اهو انهن جو تعداد وڌائڻ جو ڪو احساس ناهي. انهي حالت ۾، اهو بهتر آهي ته VM کي وڌيڪ موثر پروسيسرز سان سرور ڏانهن منتقل ڪيو وڃي.
توھان پڻ ڪوشش ڪري سگھوٿا پاور سيٽنگون سرور جي BIOS ۾. ڪيترائي منتظم BIOS ۾ اعلي ڪارڪردگي موڊ کي چالو ڪندا آھن ۽ اھڙي طرح سي-رياستن ۽ پي-رياستن جي طاقت بچائڻ واري ٽيڪنالاجي کي غير فعال ڪندا آھن. جديد Intel پروسيسرز ٽربو بوسٽ ٽيڪنالاجي استعمال ڪن ٿا، جيڪو ٻين ڪور جي خرچ تي انفرادي پروسيسر ڪور جي تعدد وڌائي ٿو. پر اهو صرف تڏهن ڪم ڪري ٿو جڏهن بجلي جي بچت واري ٽيڪنالاجيون فعال آهن. جيڪڏهن اسان انهن کي غير فعال ڪريون ٿا، ته پروسيسر ڪور جي بجلي جي استعمال کي گهٽائي نه ٿو سگهي جيڪي لوڊ نه ڪيا ويا آهن.
VMware سفارش ڪري ٿو ته سرور تي بجلي جي بچت واري ٽيڪنالاجي کي غير فعال نه ڪيو وڃي، پر طريقن کي چونڊيو جيڪو هائپرائزر کي وڌ ۾ وڌ پاور انتظام ڏئي ٿو. ساڳئي وقت، هائپرائزر پاور واهپو سيٽنگون ۾، توهان کي اعلي ڪارڪردگي چونڊڻ جي ضرورت آهي.
جيڪڏهن توهان وٽ انفرادي VMs (يا VM ڪور) آهن توهان جي انفراسٽرڪچر ۾ جنهن کي وڌايل CPU فريڪوئنسي جي ضرورت آهي، صحيح طريقي سان ترتيب ڏيڻ پاور واپرائڻ انهن جي ڪارڪردگي کي بهتر بڻائي سگهي ٿو.
سي پي يو تيار (تيار)
جيڪڏهن VM ڪور (vCPU) تيار حالت ۾ آهي، اهو ڪارائتو ڪم نٿو ڪري. اها حالت تڏهن ٿيندي آهي جڏهن هائپر وائزر هڪ مفت فزيڪل ڪور نه ڳوليندو آهي جنهن ۾ ورچوئل مشين جي وي سي پي يو عمل کي تفويض ڪري سگهجي ٿو.
تجزيو ڪيئن ڪجي؟ عام طور تي، جيڪڏهن هڪ مجازي مشين جا ڪور تيار حالت ۾ آهن 10٪ کان وڌيڪ وقت لاء، پوء توهان ڪارڪردگي مسئلن کي نوٽيس ڪندا. سادي لفظ ۾، 10٪ کان وڌيڪ وقت VM جسماني وسيلن جي دستيابي جو انتظار ڪري ٿو.
vCenter ۾، توهان CPU تيار سان لاڳاپيل 2 ڳڻپيندڙ ڏسي سگهو ٿا:
- تياري،
- تيار.
ٻنهي ڳڻپيندڙن جا قدر ڏسي سگهجن ٿا ٻنهي لاءِ پوري VM ۽ انفرادي ڪور لاءِ.
تيارگي ڏيکاري ٿو قيمت فوري طور تي فيصد طور، پر صرف حقيقي وقت ۾ (ڊيٽا آخري ڪلاڪ لاء، ماپ جي وقفي 20 سيڪنڊ). هي ڪائونٽر صرف گرم تعاقب ۾ مسئلا ڳولڻ لاءِ استعمال ڪيو ويندو آهي.
تيار ڪيل انسداد قدرن کي به تاريخي پس منظر ۾ ڏسي سگھجي ٿو. اهو نمونن کي قائم ڪرڻ ۽ مسئلي جي گہرے تجزيي لاءِ مفيد آهي. مثال طور، جيڪڏهن هڪ VM کي هڪ خاص وقت تي ڪارڪردگي جا مسئلا ٿيڻ شروع ٿين ٿا، ته توهان CPU ريڊي هورنگ وقفن جو مقابلو ڪري سگهو ٿا سرور تي مجموعي لوڊ سان جتي VM هلي رهيو آهي ۽ لوڊ کي گهٽائڻ لاءِ قدم کڻو (جيڪڏهن DRS ناڪام ٿي ويو).
تيار، تياري جي برعڪس، ڏيکاريو ويو آهي سيڪڙو ۾ نه، پر ملي سيڪنڊن ۾. هي سمشن جي قسم جو هڪ انسداد آهي، اهو آهي، اهو ڏيکاري ٿو ته ماپ جي عرصي دوران ڪيترو وقت VM ڪور تيار حالت ۾ هو. توھان ھن قدر کي ھڪڙي سادي فارمولا استعمال ڪندي في سيڪڙو ۾ تبديل ڪري سگھو ٿا:
(سي پي يو تيار ڪيل مجموعي قدر / (چارٽ ڊفالٽ اپڊيٽ وقفو سيڪنڊن ۾ * 1000)) * 100 = سي پي يو تيار٪
مثال طور، هيٺ ڏنل گراف ۾ VM لاءِ، پوري ورچوئل مشين لاءِ چوٽي تيار قيمت هوندي:
جڏهن فيصد جي طور تي تيار قيمت جي حساب سان، توهان کي ٻن نقطن تي ڌيان ڏيڻ گهرجي:
- پوري VM ۾ تيار ڪيل قيمت ڪور جي چوڌاري تيار جو مجموعو آهي.
- ماپ جو وقفو. حقيقي وقت لاء، هي 20 سيڪنڊ آهي، ۽، مثال طور، روزاني چارٽ تي، اهو 300 سيڪنڊ آهي.
فعال مصيبت جي شوٽنگ سان، اهي سادو لمحات آساني سان وڃائي سگهجن ٿا ۽ قيمتي وقت ضايع ٿي سگهي ٿو غير موجود مسئلن کي حل ڪرڻ.
اچو ته حساب ڪريون تيار ڪيل ڊيٽا جي بنياد تي هيٺ ڏنل گراف مان. (324474/(20*1000))*100 = 1622% پوري VM لاءِ. جيڪڏهن توهان ڪورن کي ڏسو ته اهو ايترو خوفناڪ ناهي: 1622/64 = 25٪ في ڪور. انهي حالت ۾، پڪڙڻ بلڪل آسان آهي: تيار قيمت غير حقيقي آهي. پر جيڪڏهن اسان ڳالهائي رهيا آهيون 10-20٪ پوري VM لاءِ ڪيترن ئي ڪورن سان، پوءِ هر ڪور لاءِ قيمت عام حد جي اندر ٿي سگهي ٿي.
آئون ڇا ڪريان؟ هڪ اعلي تيار قدر ظاهر ڪري ٿو ته سرور وٽ ڪافي پروسيسر وسيلا نه آهن مجازي مشينن جي عام آپريشن لاءِ. اهڙي صورتحال ۾، اهو صرف پروسيسر طرفان اوور سبسڪرپشن کي گهٽائڻ لاء رهي ٿو (vCPU:pCPU). ظاهر آهي، اهو حاصل ڪري سگهجي ٿو موجوده VM جي پيٽرولن کي گهٽائڻ يا VM جو حصو ٻين سرورن ڏانهن منتقل ڪندي.
همٿ
تجزيو ڪيئن ڪجي؟ ھن ڪائونٽر ۾ سميشن جو قسم آھي ۽ ان کي فيصد ۾ تبديل ڪيو ويو آھي ساڳيءَ طرح تيار:
(سي پي يو ڪو-اسٽاپ سميشن ويليو / (چارٽ ڊفالٽ اپڊيٽ وقفو سيڪنڊن ۾ * 1000)) * 100 = سي پي يو ڪو اسٽاپ٪
هتي توهان کي پڻ ڌيان ڏيڻ جي ضرورت آهي ڪور جو تعداد في VM ۽ ماپ جي وقفي تي.
قيمتي حالت ۾، ڪنييل مفيد ڪم انجام نٿو ڏئي. مناسب VM سائيز ۽ عام سرور لوڊ سان، ڪو-اسٽاپ ڪائونٽر صفر جي ويجهو هجڻ گهرجي.
انهي حالت ۾، لوڊ واضح طور تي غير معمولي آهي :)
آئون ڇا ڪريان؟ جيڪڏهن ڪيترن ئي VMs سان گڏ وڏي تعداد ۾ ڪور هڪ ئي هائپر وائيزر تي هلائي رهيا آهن ۽ سي پي يو طرفان هڪ اوور سبسڪرپشن آهي، ته پوء ڪو اسٽاپ ڪائونٽر وڌي سگهي ٿو، جيڪو انهن VMs جي ڪارڪردگي سان مسئلا پيدا ڪندو.
انهي سان گڏ، ڪو-اسٽاپ وڌي ويندو جيڪڏهن موضوع هڪ VM جي فعال ڪور لاءِ استعمال ڪيا وڃن هڪ فزيڪل سرور ڪور تي هائپر-ٽريڊنگ فعال سان. اها صورتحال ٿي سگهي ٿي، مثال طور، جيڪڏهن VM وٽ وڌيڪ ڪور آهن ان کان وڌيڪ جسماني طور تي سرور تي آهي جتي اهو هلندڙ آهي، يا جيڪڏهن "preferHT" سيٽنگ VM لاءِ فعال آهي. توھان ھن سيٽنگ بابت پڙھي سگھو ٿا. .
VM ڪارڪردگي جي مسئلن کان بچڻ لاءِ هاءِ ڪو اسٽاپ جي ڪري، VM جو سائز ٺاهيو ٺاهيندڙ جي تجويزن مطابق سافٽ ويئر لاءِ جيڪو ان VM تي هلندو آهي ۽ فزيڪل سرور جي صلاحيتون جتي VM هلندي آهي.
رزرو ۾ ڪور شامل نه ڪريو، اهو ڪارڪردگي مسئلا پيدا ڪري سگهي ٿو نه رڳو خود VM لاء، پر سرور تي ان جي پاڙيسرين لاء پڻ.
ٻيا مفيد سي پي يو ميٽرڪس
هل - ڪيتري وقت (ms) ماپ جي مدت دوران vCPU RUN رياست ۾ هو، اهو آهي، اهو اصل ۾ ڪارائتو ڪم ڪيو.
بيڪار - ماپ جي مدت دوران ڪيترو وقت (ms) vCPU بيڪار حالت ۾ هو. هاء Idle قدر ڪو مسئلو ناهي، اهو صرف اهو آهي ته وي سي پي يو وٽ "ڪجهه به نه" هو.
انتظار - ماپ جي مدت ۾ ڪيترو ڊگهو (ms) وي سي پي يو انتظار جي حالت ۾ هو. جيئن ته IDLE هن ڪائونٽر ۾ شامل ڪيو ويو آهي، اعلي انتظار جا قدر پڻ هڪ مسئلو ظاهر نٿا ڪن. پر جيڪڏهن انتظار ڪريو IDLE گھٽ آهي جڏهن وڌيڪ، ته پوء VM I / O عملن جي مڪمل ٿيڻ جو انتظار ڪري رهيو هو، ۽ اهو، بدلي ۾، هارڊ ڊسڪ يا VM جي ڪنهن به مجازي ڊوائيس جي ڪارڪردگي سان مسئلو ظاهر ڪري سگھي ٿو.
وڌ ۾ وڌ محدود - ماپ جي مدت ۾ ڪيترو وقت (ms) مقرر ڪيل وسيلن جي حد جي ڪري vCPU تيار حالت ۾ هو. جيڪڏهن ڪارڪردگي ناگزير طور تي گهٽ آهي، پوء اهو ڪارائتو آهي چيڪ ڪرڻ لاء هن انسداد جي قيمت ۽ سي پي يو جي حد VM سيٽنگون ۾. VMs شايد شايد حدون هجن جيڪي توهان نٿا ڄاڻو. مثال طور، اهو ٿئي ٿو جڏهن هڪ VM هڪ ٽيمپليٽ مان ڪلون ڪيو ويو جنهن تي سي پي يو جي حد مقرر ڪئي وئي هئي.
تبديل ڪريو انتظار ڪريو - ماپ جي مدت ۾ ڪيترو وقت تائين وي سي پي يو VMkernel Swap سان آپريشن جو انتظار ڪيو. جيڪڏهن هن انسداد جي قيمت صفر کان مٿي آهي، پوء VM ضرور ضرور ڪارڪردگي مسئلا آهي. اسان وڌيڪ ڳالهائينداسين SWAP بابت مضمون ۾ رام ڳڻپيندڙ بابت.
ESXTOP
جيڪڏهن vCenter ۾ ڪارڪردگي شمار ڪندڙ تاريخي ڊيٽا جي تجزيو ڪرڻ لاءِ سٺا آهن، ته پوءِ مسئلي جو آن لائن تجزيو ESXTOP ۾ بهتر ڪيو ويندو. هتي، سڀئي قدر پيش ڪيل فارم ۾ پيش ڪيا ويا آهن (ڪجهه به ترجمو ڪرڻ جي ضرورت ناهي)، ۽ گهٽ ۾ گهٽ ماپ جي مدت 2 سيڪنڊ آهي.
سي پي يو تي ESXTOP اسڪرين کي "c" ڪيئي سان سڏيو ويندو آهي ۽ هن وانگر ڏسڻ ۾ اچي ٿو:
سهولت لاءِ، توهان Shift-V کي دٻائڻ سان صرف ورچوئل مشين جي عمل کي ڇڏي سگهو ٿا.
انفرادي VM ڪور لاءِ ميٽرڪس ڏسڻ لاءِ، "e" کي دٻايو ۽ VM جي GID ۾ ٽائپ ڪريو جنهن ۾ توهان دلچسپي رکو ٿا (هيٺ ڏنل اسڪرين شاٽ ۾ 30919):
مان مختصر طور تي انهن ڪالمن جي ذريعي وڃان ٿو جيڪي ڊفالٽ طور پيش ڪيا ويا آهن. اضافي ڪالمن کي "f" کي دٻائڻ سان شامل ڪري سگھجي ٿو.
NWLD (دنيا جو تعداد) گروپ ۾ عملن جو تعداد آھي. گروپ کي وڌائڻ لاءِ ۽ هر عمل لاءِ ميٽرڪس ڏسو (مثال طور، ملٽي ڪور VM جي هر ڪور لاءِ)، ”اي“ کي دٻايو. جيڪڏهن هڪ گروهه ۾ هڪ کان وڌيڪ عمل آهي، ته پوءِ گروپ لاءِ ميٽرڪس انفرادي پروسيس لاءِ ميٽرڪ جي رقم جي برابر آهن.
استعمال ٿيل - ڪيترا سرور سي پي يو سائيڪل کي پروسيس ڪري ٿو يا پروسيس جو گروپ استعمال ڪري رهيو آهي.
% رن - ماپ جي مدت دوران ڪيترو ڊگهو عمل RUN رياست ۾ هو، يعني. مفيد ڪم ڪيو. %USED کان مختلف آھي ان ۾ ھائپر-ٿريڊنگ، فريڪوئنسي اسڪيلنگ، ۽ سسٽم جي ڪمن تي خرچ ٿيل وقت (%SYS) کي نظر ۾ نٿو رکي.
%SYS - سسٽم جي ڪمن تي خرچ ٿيل وقت، مثال طور: مداخلت پروسيسنگ، I / O، نيٽ ورڪنگ، وغيره. قيمت وڌيڪ ٿي سگهي ٿي جيڪڏهن VM تمام گهڻو I / O آهي.
او وي آر ايل پي - ڪيترو وقت جسماني ڪور جنهن تي VM عمل هلندڙ آهي ٻين پروسيس جي ڪمن تي خرچ ڪيو.
اهي ميٽرڪ هڪ ٻئي سان هن ريت آهن:
% استعمال = % RUN + % SYS - % OVRLP.
عام طور تي %USED ميٽرڪ وڌيڪ معلوماتي آهي.
انتظار ڪريو - ماپ جي مدت دوران ڪيترو ڊگهو عمل انتظار جي حالت ۾ هو. IDLE شامل آهي.
٪بيڪار - ماپ جي مدت ۾ ڪيترو ڊگهو عمل IDLE رياست ۾ هو.
%SWPWT - ماپ جي مدت ۾ ڪيترو وقت تائين وي سي پي يو VMkernel Swap سان آپريشن جو انتظار ڪيو.
% VMWAIT - ماپ جي مدت ۾ ڪيترو وقت وي سي پي يو واقعي جي انتظار جي حالت ۾ هو (عام طور تي I / O). vCenter ۾ ڪو به ساڳيو انسداد ناهي. اعلي قدر I/O سان مسئلا ظاهر ڪن ٿا VM تي.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
جيڪڏهن VM استعمال نٿو ڪري VMkernel Swap، پوءِ جڏهن ڪارڪردگي جي مسئلن جو تجزيو ڪيو وڃي، اهو مشورو ڏنو وڃي ٿو ته %VMWAIT، ڇو ته هي ميٽرڪ ان وقت کي نظر ۾ نٿو رکي جڏهن VM ڪجھ به نه ڪيو (%IDLE).
%RDY - ماپ جي مدت ۾ ڪيترو ڊگهو عمل تيار حالت ۾ هو.
%CSTP - ماپ جي مدت ۾ ڪيترو ڊگهو عمل اسٽاپ جي حالت ۾ هو.
%MLMTD - ماپ جي مدت ۾ ڪيترو وقت تائين وي سي پي يو تيار حالت ۾ هو ڇاڪاڻ ته مقرر ڪيل وسيلن جي حد جي ڪري.
% WAIT + % RDY + % CSTP + % RUN = 100% - VM ڪور هميشه انهن چئن رياستن مان هڪ ۾ هوندو آهي.
سي پي يو هائپرائزر تي
vCenter وٽ Hypervisor لاءِ سي پي يو پرفارمنس ڪائونٽر به آھن، پر اھي ڪجھ به دلچسپ نه آھن - اھو صرف سرور تي سڀني VMs لاءِ ڪاؤنٽرن جو مجموعو آھي.
سرور تي سي پي يو جي حالت کي ڏسڻ لاء سڀ کان وڌيڪ آسان طريقو خلاصو ٽيب تي آهي:
سرور لاء، گڏو گڏ مجازي مشين لاء، اتي هڪ معياري الارم آهي:
جڏهن سرور سي پي يو تي لوڊ تيز آهي، ان تي هلندڙ VMs ڪارڪردگي جي مسئلن جو تجربو ڪرڻ شروع ڪري ٿو.
ESXTOP ۾، سرور سي پي يو لوڊ ڊيٽا کي اسڪرين جي چوٽي تي پيش ڪيو ويو آهي. معياري سي پي يو لوڊ جي اضافي ۾، جيڪو هائپر ويزرز لاء تمام معلوماتي نه آهي، اتي ٽي وڌيڪ ميٽرڪ آهن:
ڪور يوٽيل (٪) - جسماني سرور جي ڪور جي لوڊشيڊنگ. هي ڪائونٽر ڏيکاري ٿو ڪيترو وقت ڪرنل ڪم ڪري رهيو آهي ماپ جي مدت دوران.
PCPU UTIL (%) - جيڪڏهن هائپر-ٿريڊنگ فعال آهي، ته پوءِ في فزيڪل ڪور ۾ ٻه ٿريڊ (PCPU) آهن. هي ميٽرڪ ڏيکاري ٿو ته هر موضوع ڪيترو وقت ڪم ڪري رهيو آهي.
PCPU استعمال ٿيل (%) - جيئن ته PCPU UTIL(%)، پر حساب ۾ رکي ٿو فريڪوئنسي اسڪيلنگ (يا ته پاور بچائڻ لاءِ بنيادي فريڪوئنسي کي گھٽائڻ، يا ٽربو بوسٽ ٽيڪنالاجي جي ڪري بنيادي فريڪوئنسي کي وڌائڻ) ۽ هائپر ٿريڊنگ.
PCPU_USED٪ = PCPU_UTIL٪ * مؤثر ڪور ڪلاڪ / نامياري ڪور ڪلاڪ.
ھن اسڪرين شاٽ ۾، ڪجھ ڪور لاء، ٽربو بوسٽ جي ڪري، USED قدر 100٪ کان وڌيڪ آھي، ڇاڪاڻتہ بنيادي تعدد نامياتي ھڪڙي کان وڌيڪ آھي.
هائيپر-ٿريڊنگ کي ڪئين حساب ۾ ورتو وڃي ٿو بابت ڪجھ لفظ. جيڪڏهن پروسيس تي عمل ڪيو وڃي ٿو 100٪ وقت جو سرور جي جسماني ڪور جي ٻنهي موضوعن تي، جڏهن ته ڪور نامزد تعدد تي هلندو آهي، پوء:
- ڪور لاءِ UTIL 100٪ هوندو،
- PCPU UTIL ٻنهي موضوعن لاءِ 100٪ هوندو،
- PCPU ٻنهي موضوعن لاءِ استعمال ڪيو ويندو 50٪.
جيڪڏهن ماپ جي عرصي دوران ٻنهي ٿريڊن 100 سيڪڙو ڪم نه ڪيو، ته پوءِ انهن دورن ۾ جڏهن ٿريڊس متوازي ڪم ڪندا هئا، ته PCPU استعمال ٿيل ڪور لاءِ اڌ ٿي ويندو آهي.
ESXTOP وٽ پڻ هڪ اسڪرين آهي سرور سي پي يو پاور اختيارن سان. هتي توهان ڏسي سگهو ٿا ته سرور استعمال ڪري ٿو توانائي-بچت ٽيڪنالاجيون: C-states ۽ P-states. "p" جي ذريعي سڏيو ويندو آهي:
عام سي پي يو ڪارڪردگي مسئلا
آخرڪار، مان وي ايم سي پي يو ڪارڪردگي سان مسئلن جي عام سببن تي وڃو ۽ انهن کي حل ڪرڻ لاء مختصر صلاحون ڏيندس:
ڪافي بنيادي ڪلاڪ نه آهي. جيڪڏهن اهو ممڪن ناهي ته VM کي وڌيڪ طاقتور ڪور ڏانهن اپڊيٽ ڪيو وڃي، توهان ڪوشش ڪري سگهو ٿا پاور سيٽنگون تبديل ڪرڻ ته جيئن ٽربو بوسٽ وڌيڪ ڪارائتو ڪم ڪري.
غلط VM سائيز (تمام گھڻا / ڪجھ ڪور). جيڪڏهن توهان ڪجهه ڪور رکيا، اتي وي ايم جي سي پي يو تي هڪ وڏو لوڊ هوندو. جيڪڏهن تمام گهڻو، هڪ اعلي ڪو اسٽاپ کي پڪڙيو.
سرور تي وڏي سي پي يو اوور سبسڪرپشن. جيڪڏهن VM اعلي آهي تيار، سي پي يو اوور سبسڪرپشن کي گهٽ ڪريو.
وڏي VMs تي غلط NUMA ٽوپولوجي. VM (vNUMA) پاران ڏٺل NUMA ٽوپولاجيءَ کي سرور جي NUMA ٽوپولوجي (pNUMA) سان ملندو. هن مسئلي جي تشخيص ۽ ممڪن حل بابت، مثال طور، ڪتاب ۾ لکيو ويو آهي . جيڪڏهن توهان نه ٿا چاهيو ته اوندهه ۾ وڃو ۽ توهان وٽ VM تي نصب ٿيل OS تي لائسنس جون پابنديون نه آهن، هڪ ڪور لاءِ VM تي ڪيترائي ورچوئل ساکٽ ٺاهيو. توهان گهڻو نه وڃايو 🙂
اهو سڀ ڪجهه مون لاءِ سي پي يو بابت آهي. سوال پڇو. ايندڙ حصي ۾ مان RAM بابت ڳالهائيندس.
ڪارآمد لنڪ
جو ذريعو: www.habr.com