اگر آپ VMware vSphere (یا کسی دوسرے ٹکنالوجی اسٹیک) پر مبنی ایک ورچوئل انفراسٹرکچر کا انتظام کرتے ہیں تو، آپ کو اکثر صارفین کی طرف سے شکایات سننے کو ملتی ہیں: "ورچوئل مشین سست ہے!" مضامین کے اس سلسلے میں میں کارکردگی کے میٹرکس کا تجزیہ کروں گا اور آپ کو بتاؤں گا کہ یہ کیا اور کیوں سست ہوتا ہے اور یہ کیسے یقینی بنایا جائے کہ یہ سست نہ ہو۔
میں ورچوئل مشین کی کارکردگی کے درج ذیل پہلوؤں پر غور کروں گا:
- سی پی یو ،
- رام،
- ڈسک،
- نیٹ ورک
میں CPU کے ساتھ شروع کروں گا۔
کارکردگی کا تجزیہ کرنے کے لیے ہمیں ضرورت ہو گی:
- vCenter پرفارمنس کاؤنٹرز - کارکردگی کاؤنٹر، جن کے گراف vSphere کلائنٹ کے ذریعے دیکھے جا سکتے ہیں۔ ان کاؤنٹرز پر معلومات کلائنٹ کے کسی بھی ورژن میں دستیاب ہے (C# میں "موٹا" کلائنٹ، Flex میں ویب کلائنٹ اور HTML5 میں ویب کلائنٹ)۔ ان مضامین میں ہم C# کلائنٹ کے اسکرین شاٹس استعمال کریں گے، صرف اس لیے کہ وہ چھوٹے میں بہتر نظر آتے ہیں :)
- ESXTOP - ایک افادیت جو ESXi کمانڈ لائن سے چلتی ہے۔ اس کی مدد سے، آپ ریئل ٹائم میں پرفارمنس کاؤنٹرز کی قدریں حاصل کر سکتے ہیں یا ان اقدار کو ایک خاص مدت کے لیے مزید تجزیہ کے لیے .csv فائل میں اپ لوڈ کر سکتے ہیں۔ اگلا، میں آپ کو اس ٹول کے بارے میں مزید بتاؤں گا اور اس موضوع پر دستاویزات اور مضامین کے کئی مفید لنکس فراہم کروں گا۔
تھوڑا سا اصول
ESXi میں، ایک الگ عمل - VMware اصطلاحات میں دنیا - ہر vCPU (ورچوئل مشین کور) کے آپریشن کے لیے ذمہ دار ہے۔ سروس کے عمل بھی ہیں، لیکن VM کارکردگی کا تجزیہ کرنے کے نقطہ نظر سے وہ کم دلچسپ ہیں۔
ESXi میں عمل چار ریاستوں میں سے کسی ایک میں ہو سکتا ہے:
- رن - یہ عمل کچھ مفید کام انجام دیتا ہے۔
- انتظار کریں - عمل کوئی کام نہیں کر رہا ہے (بیکار) یا ان پٹ/آؤٹ پٹ کا انتظار کر رہا ہے۔
- کوسٹاپ - ایک ایسی حالت جو ملٹی کور ورچوئل مشینوں میں ہوتی ہے۔ یہ اس وقت ہوتا ہے جب ہائپر وائزر CPU شیڈیولر (ESXi CPU شیڈیولر) فزیکل سرور کورز پر تمام فعال ورچوئل مشین کورز کے بیک وقت عمل درآمد کو شیڈول نہیں کر سکتا۔ طبعی دنیا میں، تمام پروسیسر کور متوازی طور پر کام کرتے ہیں، VM کے اندر موجود مہمان OS سے اسی طرح کے رویے کی توقع ہوتی ہے، اس لیے ہائپر وائزر کو VM کور کو سست کرنا پڑتا ہے جو اپنے کلاک سائیکل کو تیزی سے ختم کرنے کی صلاحیت رکھتے ہیں۔ ESXi کے جدید ورژن میں، CPU شیڈیولر ایک طریقہ کار استعمال کرتا ہے جسے ریلیکسڈ کو-شیڈیولنگ کہا جاتا ہے: ہائپر وائزر "تیز ترین" اور "سست ترین" ورچوئل مشین کور (سکیو) کے درمیان فرق پر غور کرتا ہے۔ اگر خلا ایک خاص حد سے تجاوز کر جاتا ہے، تو فاسٹ کور کوسٹاپ حالت میں داخل ہو جاتا ہے۔ اگر VM کور اس حالت میں بہت زیادہ وقت گزارتے ہیں، تو یہ کارکردگی کے مسائل کا سبب بن سکتا ہے۔
- کے لئے تیار ہیں - عمل اس حالت میں داخل ہوتا ہے جب ہائپر وائزر اپنے عمل کے لیے وسائل مختص کرنے سے قاصر ہوتا ہے۔ اعلیٰ تیار اقدار VM کارکردگی کے مسائل کا سبب بن سکتی ہیں۔
بنیادی ورچوئل مشین سی پی یو پرفارمنس کاؤنٹرز
سی پی یو کا استعمال، ٪. ایک مقررہ مدت کے لیے CPU کے استعمال کا فیصد دکھاتا ہے۔
تجزیہ کیسے کریں؟ اگر VM مستقل طور پر 90% پر CPU استعمال کرتا ہے یا 100% تک چوٹیاں ہیں، تو ہمیں پریشانی ہوتی ہے۔ مسائل کا اظہار نہ صرف VM کے اندر ایپلیکیشن کے "سست" آپریشن میں کیا جا سکتا ہے، بلکہ نیٹ ورک پر VM کی ناقابل رسائی میں بھی۔ اگر نگرانی کا نظام یہ ظاہر کرتا ہے کہ VM وقفے وقفے سے گرتا ہے، تو CPU کے استعمال کے گراف میں چوٹیوں پر توجہ دیں۔
ایک معیاری الارم ہے جو ورچوئل مشین کا CPU لوڈ دکھاتا ہے:
کیا؟ اگر VM کا CPU استعمال مسلسل چھت سے گزر رہا ہے، تو آپ vCPUs کی تعداد بڑھانے کے بارے میں سوچ سکتے ہیں (بدقسمتی سے، یہ ہمیشہ مدد نہیں کرتا) یا VM کو زیادہ طاقتور پروسیسرز والے سرور پر منتقل کرنے کے بارے میں سوچ سکتے ہیں۔
میگاہرٹز میں سی پی یو کا استعمال
% میں vCenter کے استعمال کے گراف میں آپ صرف پوری ورچوئل مشین کے لیے دیکھ سکتے ہیں؛ انفرادی کور کے لیے کوئی گراف نہیں ہیں (Extop میں cores کے لیے % اقدار ہیں)۔ ہر کور کے لیے آپ MHz میں استعمال دیکھ سکتے ہیں۔
تجزیہ کیسے کریں؟ ایسا ہوتا ہے کہ ایک ایپلیکیشن کو ملٹی کور فن تعمیر کے لیے بہتر نہیں بنایا گیا ہے: اس میں صرف ایک کور 100% استعمال ہوتا ہے، اور باقی بغیر بوجھ کے بے کار ہیں۔ مثال کے طور پر، ڈیفالٹ بیک اپ سیٹنگز کے ساتھ، MS SQL صرف ایک کور پر عمل شروع کرتا ہے۔ نتیجے کے طور پر، بیک اپ سست ہوجاتا ہے کیونکہ ڈسک کی سست رفتار (یہ وہی ہے جس کے بارے میں صارف نے ابتدائی طور پر شکایت کی تھی)، لیکن اس وجہ سے کہ پروسیسر کا مقابلہ نہیں کرسکتا. مسئلہ پیرامیٹرز کو تبدیل کرکے حل کیا گیا تھا: بیک اپ متعدد فائلوں میں متوازی طور پر چلنا شروع ہوا (بالترتیب، کئی عملوں میں)۔
کور پر ناہموار بوجھ کی ایک مثال۔
ایک ایسی صورتحال بھی ہے (جیسا کہ اوپر گراف میں ہے) جب کور غیر مساوی طور پر لوڈ ہوتے ہیں اور ان میں سے کچھ کی چوٹی 100٪ ہوتی ہے۔ جیسا کہ صرف ایک کور لوڈ کرنے کے ساتھ، CPU کے استعمال کے لیے الارم کام نہیں کرے گا (یہ پورے VM کے لیے ہے)، لیکن کارکردگی کے مسائل ہوں گے۔
کیا؟ اگر ورچوئل مشین میں سافٹ ویئر کور کو غیر مساوی طور پر لوڈ کرتا ہے (صرف ایک کور یا کور کا کچھ حصہ استعمال کرتا ہے)، تو ان کی تعداد بڑھانے کا کوئی فائدہ نہیں ہے۔ اس صورت میں، VM کو زیادہ طاقتور پروسیسرز والے سرور پر منتقل کرنا بہتر ہے۔
آپ سرور BIOS میں بجلی کی کھپت کی ترتیبات کو بھی چیک کرنے کی کوشش کر سکتے ہیں۔ بہت سے منتظمین BIOS میں ہائی پرفارمنس موڈ کو فعال کرتے ہیں اور اس طرح C-states اور P-states انرجی سیونگ ٹیکنالوجیز کو غیر فعال کر دیتے ہیں۔ جدید انٹیل پروسیسر ٹربو بوسٹ ٹیکنالوجی کا استعمال کرتے ہیں، جو دوسرے کور کی قیمت پر انفرادی پروسیسر کور کی تعدد کو بڑھاتا ہے۔ لیکن یہ صرف اس وقت کام کرتا ہے جب توانائی کی بچت کی ٹیکنالوجیز آن ہوں۔ اگر ہم انہیں غیر فعال کر دیتے ہیں، تو پروسیسر لوڈ نہ ہونے والے کوروں کی بجلی کی کھپت کو کم نہیں کر سکتا۔
VMware تجویز کرتا ہے کہ سرورز پر پاور سیونگ ٹیکنالوجیز کو غیر فعال نہ کریں، بلکہ ایسے طریقوں کا انتخاب کریں جو پاور مینجمنٹ کو زیادہ سے زیادہ ہائپر وائزر پر چھوڑ دیں۔ اس صورت میں، ہائپر وائزر بجلی کی کھپت کی ترتیبات میں، آپ کو ہائی پرفارمنس کو منتخب کرنے کی ضرورت ہے۔
اگر آپ کے انفراسٹرکچر میں انفرادی VMs (یا VM cores) ہیں جن کے لیے CPU فریکوئنسی میں اضافہ کی ضرورت ہوتی ہے، تو بجلی کی کھپت کو درست طریقے سے ایڈجسٹ کرنا ان کی کارکردگی کو نمایاں طور پر بہتر بنا سکتا ہے۔
سی پی یو تیار ہے۔
اگر VM کور (vCPU) تیار حالت میں ہے، تو یہ مفید کام نہیں کرتا ہے۔ یہ حالت اس وقت ہوتی ہے جب ہائپر وائزر کو کوئی مفت فزیکل کور نہیں ملتا ہے جس میں ورچوئل مشین کا vCPU عمل تفویض کیا جا سکتا ہے۔
تجزیہ کیسے کریں؟ عام طور پر، اگر کسی ورچوئل مشین کے کور 10% سے زیادہ وقت تیار حالت میں ہوتے ہیں، تو آپ کو کارکردگی کے مسائل نظر آئیں گے۔ سیدھے الفاظ میں، VM کے 10% سے زیادہ وقت جسمانی وسائل کے دستیاب ہونے کا انتظار کرتا ہے۔
vCenter میں آپ CPU ریڈی سے متعلق 2 کاؤنٹرز دیکھ سکتے ہیں:
- تیاری،
- تیار.
دونوں کاؤنٹرز کی قدریں پورے VM اور انفرادی کور دونوں کے لیے دیکھی جا سکتی ہیں۔
تیاری فی صد کے طور پر فوری طور پر قدر ظاہر کرتی ہے، لیکن صرف حقیقی وقت میں (آخری گھنٹے کا ڈیٹا، پیمائش کا وقفہ 20 سیکنڈ)۔ بہتر ہے کہ اس کاؤنٹر کو صرف مسائل کی تلاش کے لیے استعمال کیا جائے "ایڑیوں پر گرم"۔
ریڈی کاؤنٹر ویلیوز کو تاریخی نقطہ نظر سے بھی دیکھا جا سکتا ہے۔ یہ پیٹرن قائم کرنے اور مسئلے کے گہرے تجزیہ کے لیے مفید ہے۔ مثال کے طور پر، اگر ایک ورچوئل مشین کسی خاص وقت پر کارکردگی کے مسائل کا سامنا کرنا شروع کر دیتی ہے، تو آپ CPU ریڈی ویلیو کے وقفوں کا موازنہ سرور پر موجود کل بوجھ کے ساتھ کر سکتے ہیں جہاں یہ VM چل رہا ہے، اور بوجھ کو کم کرنے کے اقدامات کر سکتے ہیں (اگر DRS ناکام ہوجاتا ہے)۔
ریڈی، ریڈینس کے برعکس، فیصد میں نہیں بلکہ ملی سیکنڈ میں دکھایا گیا ہے۔ یہ سمیشن قسم کا کاؤنٹر ہے، یعنی یہ ظاہر کرتا ہے کہ پیمائش کی مدت کے دوران VM کور کتنی دیر تک تیار حالت میں تھا۔ آپ ایک سادہ فارمولے کا استعمال کرتے ہوئے اس قدر کو فیصد میں تبدیل کر سکتے ہیں:
(سی پی یو ریڈی سمیشن ویلیو / (چارٹ ڈیفالٹ اپ ڈیٹ کا وقفہ سیکنڈز میں * 1000)) * 100 = CPU تیار %
مثال کے طور پر، نیچے دیے گئے گراف میں VM کے لیے، پوری ورچوئل مشین کے لیے چوٹی ریڈی ویلیو اس طرح ہوگی:
تیار فیصد کا حساب لگاتے وقت، آپ کو دو نکات پر توجہ دینا چاہئے:
- پورے VM کے لیے ریڈی ویلیو تمام کور کے ریڈی کا مجموعہ ہے۔
- پیمائش کا وقفہ۔ ریئل ٹائم کے لیے یہ 20 سیکنڈ ہے، اور مثال کے طور پر، روزانہ چارٹ پر یہ 300 سیکنڈ ہے۔
فعال ٹربل شوٹنگ کے ساتھ، یہ آسان نکات آسانی سے چھوٹ سکتے ہیں اور غیر موجود مسائل کو حل کرنے میں قیمتی وقت ضائع کیا جا سکتا ہے۔
آئیے نیچے دیے گئے گراف کے ڈیٹا کی بنیاد پر ریڈی کا حساب لگاتے ہیں۔ (324474/(20*1000))*100 = 1622% پورے VM کے لیے۔ اگر آپ کور کو دیکھیں تو یہ اتنا خوفناک نہیں ہے: 1622/64 = 25% فی کور۔ اس صورت میں، کیچ کو تلاش کرنا کافی آسان ہے: ریڈی ویلیو غیر حقیقی ہے۔ لیکن اگر ہم کئی کور والے پورے VM کے لیے 10-20% کے بارے میں بات کر رہے ہیں، تو ہر کور کے لیے قدر معمول کی حد کے اندر ہو سکتی ہے۔
کیا؟ ایک اعلی ریڈی ویلیو اس بات کی نشاندہی کرتی ہے کہ سرور کے پاس ورچوئل مشینوں کے نارمل آپریشن کے لیے کافی پروسیسر وسائل نہیں ہیں۔ ایسی صورت حال میں، پروسیسر (vCPU:pCPU) کے ذریعے اوور سبسکرپشن کو کم کرنا باقی رہ جاتا ہے۔ ظاہر ہے، یہ موجودہ VMs کے پیرامیٹرز کو کم کر کے یا VMs کے کچھ حصے کو دوسرے سرورز پر منتقل کر کے حاصل کیا جا سکتا ہے۔
شریک سٹاپ
تجزیہ کیسے کریں؟ یہ کاؤنٹر بھی سمیشن قسم کا ہے اور اسے فیصد میں اسی طرح تبدیل کیا جاتا ہے جس طرح تیار ہے:
(سی پی یو کو-اسٹاپ سمیشن ویلیو / (سیکنڈز میں چارٹ ڈیفالٹ اپ ڈیٹ وقفہ * 1000)) * 100 = CPU کو-اسٹاپ %
یہاں آپ کو VM پر کور کی تعداد اور پیمائش کے وقفے پر بھی توجہ دینے کی ضرورت ہے۔
کوسٹاپ حالت میں، دانا مفید کام نہیں کرتا ہے۔ سرور پر VM سائز اور نارمل لوڈ کے درست انتخاب کے ساتھ، کو-اسٹاپ کاؤنٹر صفر کے قریب ہونا چاہیے۔
اس صورت میں، بوجھ واضح طور پر غیر معمولی ہے :)
کیا؟ اگر ایک ہائپر وائزر پر بڑی تعداد میں کور والے کئی VM چل رہے ہیں اور CPU پر اوور سبسکرپشن ہے، تو کو-اسٹاپ کاؤنٹر بڑھ سکتا ہے، جس سے ان VMs کی کارکردگی میں مسائل پیدا ہوں گے۔
نیز، کو-اسٹاپ بڑھے گا اگر ایک VM کے فعال کور ایک فزیکل سرور کور پر دھاگوں کا استعمال کرتے ہیں جس میں ہائپر ٹریڈنگ فعال ہے۔ یہ صورت حال پیدا ہو سکتی ہے، مثال کے طور پر، اگر VM کے پاس سرور پر جسمانی طور پر دستیاب سے زیادہ کور ہیں جہاں یہ چل رہا ہے، یا اگر VM کے لیے "preferHT" سیٹنگ فعال ہے۔ آپ اس ترتیب کے بارے میں پڑھ سکتے ہیں۔ .
اعلی کو-اسٹاپ کی وجہ سے VM کی کارکردگی میں مسائل سے بچنے کے لیے، اس VM پر چلنے والے سافٹ ویئر کے مینوفیکچرر کی سفارشات اور جہاں VM چلتا ہے وہاں کے فزیکل سرور کی صلاحیتوں کے مطابق VM سائز منتخب کریں۔
ریزرو میں کور شامل نہ کریں؛ اس سے نہ صرف خود VM بلکہ سرور پر اس کے پڑوسیوں کے لیے بھی کارکردگی کے مسائل پیدا ہو سکتے ہیں۔
دیگر مفید CPU میٹرکس
رن - پیمائش کی مدت کے دوران کتنا وقت (ms) vCPU RUN حالت میں تھا، یعنی یہ واقعی مفید کام انجام دے رہا تھا۔
ناقابل یقین - پیمائش کی مدت کے دوران کتنی دیر (ms) vCPU غیر فعال حالت میں تھا۔ اعلی بیکار اقدار کوئی مسئلہ نہیں ہیں، vCPU کے پاس صرف "کچھ کرنے کو نہیں تھا۔"
انتظار کریں - پیمائش کی مدت کے دوران کتنی دیر (ms) vCPU انتظار کی حالت میں تھا۔ چونکہ IDLE اس کاؤنٹر میں شامل ہے، اعلیٰ انتظار کی قدریں بھی کسی مسئلے کی نشاندہی نہیں کرتی ہیں۔ لیکن اگر Wait زیادہ ہونے پر Wait IDLE کم ہے، تو اس کا مطلب ہے کہ VM I/O آپریشنز مکمل ہونے کا انتظار کر رہا تھا، اور اس کے نتیجے میں، ہارڈ ڈرائیو یا VM کے کسی بھی ورچوئل ڈیوائسز کی کارکردگی میں دشواری کی نشاندہی ہو سکتی ہے۔
زیادہ سے زیادہ محدود - پیمائش کی مدت کے دوران کتنی دیر تک (ms) وسائل کی مقررہ حد کی وجہ سے vCPU تیار حالت میں تھا۔ اگر کارکردگی ناقابل فہم طور پر کم ہے، تو VM سیٹنگز میں اس کاؤنٹر کی قدر اور CPU کی حد کو چیک کرنا مفید ہے۔ VMs کی واقعی حدود ہوسکتی ہیں جن سے آپ واقف نہیں ہیں۔ مثال کے طور پر، ایسا اس وقت ہوتا ہے جب کسی ٹیمپلیٹ سے VM کو کلون کیا گیا تھا جس پر CPU کی حد سیٹ کی گئی تھی۔
تبدیل کریں انتظار کریں۔ - پیمائش کی مدت کے دوران کتنی دیر تک vCPU نے VMkernel Swap کے ساتھ آپریشن کا انتظار کیا۔ اگر اس کاؤنٹر کی قدریں صفر سے اوپر ہیں، تو یقینی طور پر VM میں کارکردگی کے مسائل ہیں۔ ہم RAM کاؤنٹرز کے بارے میں مضمون میں SWAP کے بارے میں مزید بات کریں گے۔
ESXTOP
اگر vCenter میں پرفارمنس کاؤنٹر تاریخی ڈیٹا کا تجزیہ کرنے کے لیے اچھے ہیں، تو ESXTOP میں مسئلے کا آپریشنل تجزیہ بہتر طریقے سے کیا جاتا ہے۔ یہاں، تمام اقدار تیار شدہ شکل میں پیش کی جاتی ہیں (کسی بھی چیز کا ترجمہ کرنے کی ضرورت نہیں ہے)، اور کم از کم پیمائش کی مدت 2 سیکنڈ ہے.
CPU کے لیے ESXTOP اسکرین کو "c" کلید کے ساتھ کال کیا جاتا ہے اور یہ اس طرح دکھائی دیتی ہے:
سہولت کے لیے، آپ Shift-V کو دبا کر صرف ورچوئل مشین کے عمل کو چھوڑ سکتے ہیں۔
انفرادی VM کور کے لیے میٹرکس دیکھنے کے لیے، "e" دبائیں اور دلچسپی کے VM کا GID درج کریں (نیچے اسکرین شاٹ میں 30919):
میں مختصراً ان کالموں کو دیکھتا ہوں جو بطور ڈیفالٹ پیش کیے جاتے ہیں۔ "f" دبانے سے اضافی کالم شامل کیے جا سکتے ہیں۔
NWLD (دنیا کی تعداد) - گروپ میں عمل کی تعداد۔ گروپ کو پھیلانے اور ہر عمل کے لیے میٹرکس دیکھنے کے لیے (مثال کے طور پر، ملٹی کور VM میں ہر کور کے لیے)، "e" کو دبائیں۔ اگر ایک گروپ میں ایک سے زیادہ عمل ہیں، تو گروپ کے لیے میٹرک ویلیوز انفرادی عمل کے لیے میٹرکس کے مجموعے کے برابر ہیں۔
استعمال شدہ - ایک عمل یا عمل کے گروپ کے ذریعہ کتنے سرور CPU سائیکل استعمال کیے جاتے ہیں۔
٪رن - پیمائش کی مدت کے دوران عمل کتنی دیر تک RUN حالت میں تھا، یعنی مفید کام کیا. یہ %USED سے اس لحاظ سے مختلف ہے کہ اس میں ہائپر تھریڈنگ، فریکوئنسی اسکیلنگ اور سسٹم ٹاسک (%SYS) پر خرچ ہونے والے وقت کو مدنظر نہیں رکھا جاتا ہے۔
%SYS - سسٹم کے کاموں پر خرچ ہونے والا وقت، مثال کے طور پر: مداخلت پروسیسنگ، I/O، نیٹ ورک آپریشن وغیرہ۔ اگر VM میں I/O بڑا ہو تو قیمت زیادہ ہو سکتی ہے۔
OVRLP - فزیکل کور جس پر VM عمل چل رہا ہے دوسرے عمل کے کاموں میں کتنا وقت صرف کرتا ہے۔
یہ میٹرکس ایک دوسرے سے مندرجہ ذیل ہیں:
%USED = %RUN + %SYS - %OVRLP۔
عام طور پر %USED میٹرک زیادہ معلوماتی ہوتا ہے۔
انتظار کریں۔ - پیمائش کی مدت کے دوران عمل کتنی دیر انتظار کی حالت میں تھا۔ IDLE کو فعال کرتا ہے۔
%IDLE - پیمائش کی مدت کے دوران عمل کتنی دیر تک IDLE حالت میں تھا۔
%SWPWT - پیمائش کی مدت کے دوران کتنی دیر تک vCPU نے VMkernel Swap کے ساتھ آپریشن کا انتظار کیا۔
VMWAIT - پیمائش کی مدت کے دوران کتنی دیر تک vCPU کسی ایونٹ کے انتظار کی حالت میں تھا (عام طور پر I/O)۔ vCenter میں اس جیسا کوئی کاؤنٹر نہیں ہے۔ اعلی اقدار VM پر I/O کے ساتھ مسائل کی نشاندہی کرتی ہیں۔
%WAIT = %VMWAIT + %IDLE + %SWPWT۔
اگر VM VMkernel Swap استعمال نہیں کرتا ہے، تو کارکردگی کے مسائل کا تجزیہ کرتے وقت %VMWAIT کو دیکھنے کا مشورہ دیا جاتا ہے، کیونکہ یہ میٹرک اس وقت کو مدنظر نہیں رکھتا جب VM کچھ نہیں کر رہا تھا (%IDLE)۔
%RDY - پیمائش کی مدت کے دوران عمل کتنی دیر تک تیار حالت میں تھا۔
%CSTP - پیمائش کی مدت کے دوران عمل کتنی دیر تک کوسٹاپ حالت میں تھا۔
%MLMTD - وسائل کی مقررہ حد کی وجہ سے پیمائش کی مدت کے دوران vCPU تیار حالت میں کتنا عرصہ تھا۔
%WAIT + %RDY + %CSTP + %RUN = 100% – VM کور ہمیشہ ان چار ریاستوں میں سے ایک میں ہوتا ہے۔
ہائپرائزر پر سی پی یو
vCenter میں ہائپر وائزر کے لیے CPU پرفارمنس کاؤنٹرز بھی ہیں، لیکن وہ کچھ بھی دلچسپ نہیں ہیں - وہ صرف سرور پر موجود تمام VMs کے کاؤنٹرز کا مجموعہ ہیں۔
سرور پر سی پی یو کی حیثیت کو دیکھنے کا سب سے آسان طریقہ خلاصہ ٹیب پر ہے:
سرور کے ساتھ ساتھ ورچوئل مشین کے لیے بھی ایک معیاری الارم ہے:
جب سرور CPU لوڈ زیادہ ہوتا ہے، تو اس پر چلنے والے VMs کو کارکردگی کے مسائل کا سامنا کرنا شروع ہو جاتا ہے۔
ESXTOP میں، سرور CPU لوڈ ڈیٹا اسکرین کے اوپری حصے میں پیش کیا جاتا ہے۔ معیاری CPU لوڈ کے علاوہ، جو کہ ہائپر وائزرز کے لیے زیادہ معلوماتی نہیں ہے، تین اور میٹرکس ہیں:
کور UTIL(%) - فزیکل سرور کور کو لوڈ کرنا۔ یہ کاؤنٹر دکھاتا ہے کہ پیمائش کی مدت کے دوران کور نے کتنا وقت کام کیا۔
PCPU UTIL(%) - اگر ہائپر تھریڈنگ فعال ہے، تو فی فزیکل کور میں دو تھریڈز (PCPU) ہوتے ہیں۔ یہ میٹرک دکھاتا ہے کہ ہر تھریڈ کو کام مکمل ہونے میں کتنا وقت لگا۔
PCPU استعمال کیا گیا (%) - PCPU UTIL(%) کی طرح، لیکن فریکوئنسی اسکیلنگ (یا تو توانائی کی بچت کے مقاصد کے لیے کور فریکوئنسی کو کم کرنا، یا ٹربو بوسٹ ٹیکنالوجی کی وجہ سے کور فریکوئنسی میں اضافہ) اور ہائپر تھریڈنگ کو مدنظر رکھتا ہے۔
PCPU_USED% = PCPU_UTIL% * موثر کور فریکوئنسی / برائے نام کور فریکوئنسی۔
اس اسکرین شاٹ میں، کچھ کوروں کے لیے، ٹربو بوسٹ کی وجہ سے، USED قدر 100% سے زیادہ ہے، کیونکہ بنیادی تعدد برائے نام سے زیادہ ہے۔
ہائپر تھریڈنگ کو کیسے مدنظر رکھا جاتا ہے اس کے بارے میں چند الفاظ۔ اگر سرور کے فزیکل کور کے دونوں تھریڈز پر 100% وقت پر عمل کیا جاتا ہے، جبکہ کور برائے نام فریکوئنسی پر کام کرتا ہے، تو:
- کور کے لیے CORE UTIL 100% ہو گا،
- دونوں تھریڈز کے لیے PCPU UTIL 100% ہو گا،
- دونوں دھاگوں کے لیے استعمال شدہ PCPU %50 ہوگا۔
اگر دونوں تھریڈز پیمائش کی مدت کے دوران 100% کام نہیں کرتے ہیں، تو ان ادوار کے دوران جب تھریڈز متوازی طور پر کام کرتے تھے، کور کے لیے استعمال شدہ PCPU نصف میں تقسیم ہوتا ہے۔
ESXTOP میں سرور CPU بجلی کی کھپت کے پیرامیٹرز کے ساتھ ایک اسکرین بھی ہے۔ یہاں آپ دیکھ سکتے ہیں کہ آیا سرور توانائی کی بچت کی ٹیکنالوجیز استعمال کرتا ہے: C-states اور P-states۔ "p" کلید کے ساتھ کال کی گئی:
عام سی پی یو کارکردگی کے مسائل
آخر میں، میں VM CPU کی کارکردگی کے ساتھ مسائل کی عام وجوہات پر جاؤں گا اور ان کو حل کرنے کے لیے مختصر تجاویز دوں گا:
بنیادی گھڑی کی رفتار کافی نہیں ہے۔ اگر آپ کے VM کو زیادہ طاقتور کور میں اپ گریڈ کرنا ممکن نہیں ہے، تو آپ ٹربو بوسٹ کو زیادہ موثر طریقے سے کام کرنے کے لیے پاور سیٹنگز کو تبدیل کرنے کی کوشش کر سکتے ہیں۔
غلط VM سائزنگ (بہت زیادہ/کچھ کور)۔ اگر آپ کچھ کور انسٹال کرتے ہیں، تو VM پر زیادہ CPU لوڈ ہوگا۔ اگر بہت کچھ ہے تو، ایک اعلی شریک سٹاپ کو پکڑو.
سرور پر CPU کی بڑی اوور سبسکرپشن۔ اگر VM زیادہ تیار ہے، تو CPU اوور سبسکرپشن کو کم کریں۔
بڑے VMs پر غلط NUMA ٹوپولوجی۔ VM (vNUMA) کے ذریعہ دیکھی گئی NUMA ٹوپولوجی سرور (pNUMA) کی NUMA ٹوپولوجی سے مماثل ہونی چاہئے۔ اس مسئلے کی تشخیص اور ممکنہ حل لکھے گئے ہیں، مثال کے طور پر، کتاب میں . اگر آپ گہرائی میں نہیں جانا چاہتے ہیں اور آپ کے پاس VM پر نصب OS پر لائسنسنگ کی پابندیاں نہیں ہیں، تو VM پر بہت سے ورچوئل ساکٹ بنائیں، ایک وقت میں ایک کور۔ آپ زیادہ نہیں کھویں گے :)
سی پی یو کے بارے میں میرے لئے یہی ہے۔ سوالات پوچھیے. اگلے حصے میں میں رام کے بارے میں بات کروں گا۔
کارآمد ویب سائٹس
ماخذ: www.habr.com