چوری: جو ورچوئل مشینوں سے پروسیسر کا وقت چوری کرتا ہے۔

چوری: جو ورچوئل مشینوں سے پروسیسر کا وقت چوری کرتا ہے۔

ہیلو! میں آپ کو ورچوئل مشینوں کے اندر چوری کرنے کے میکانکس کے بارے میں اور کچھ غیر واضح نمونوں کے بارے میں آسان الفاظ میں بتانا چاہتا ہوں جو ہم اس کی تحقیق کے دوران تلاش کرنے میں کامیاب ہوئے، جس میں مجھے ایک کلاؤڈ پلیٹ فارم کے ٹیکنیکل ڈائریکٹر کے طور پر جانا پڑا۔ Mail.ru کلاؤڈ سلوشنز. پلیٹ فارم KVM پر چلتا ہے۔

CPU اسٹیل ٹائم وہ وقت ہوتا ہے جس کے دوران ورچوئل مشین کو اس کے عمل کے لیے پروسیسر کے وسائل نہیں ملتے ہیں۔ اس وقت کو صرف ورچوئلائزیشن ماحول میں مہمان آپریٹنگ سسٹم میں شمار کیا جاتا ہے۔ یہ سب سے زیادہ مختص وسائل کہاں جاتے ہیں اس کی وجوہات، جیسا کہ زندگی میں، بہت مبہم ہیں۔ لیکن ہم نے اس کا پتہ لگانے کا فیصلہ کیا، اور یہاں تک کہ کئی تجربات بھی کئے۔ ایسا نہیں ہے کہ اب ہم چوری کے بارے میں سب کچھ جانتے ہیں، لیکن اب ہم آپ کو ایک دلچسپ بات بتائیں گے۔

1. چوری کیا ہے؟

لہذا، چوری ایک میٹرک ہے جو ورچوئل مشین کے اندر عمل کے لیے پروسیسر کے وقت کی کمی کی نشاندہی کرتا ہے۔ جیسا کے بتایا گیا KVM کرنل پیچ میںاسٹیلتھ وہ وقت ہوتا ہے جس کے دوران ہائپر وائزر میزبان OS پر دوسرے عمل کو انجام دے رہا ہوتا ہے حالانکہ اس نے عمل درآمد کے لیے ورچوئل مشین کے عمل کو قطار میں کھڑا کر دیا ہے۔ یعنی، چوری کا حساب اس وقت کے درمیان فرق کے طور پر کیا جاتا ہے جب عمل کو انجام دینے کے لیے تیار ہوتا ہے اور اس وقت جب عمل کو پروسیسر کا وقت مختص کیا جاتا ہے۔

ورچوئل مشین کرنل ہائپر وائزر سے اسٹیل میٹرک وصول کرتا ہے۔ ایک ہی وقت میں، ہائپر وائزر بالکل واضح نہیں کرتا کہ یہ کون سے دوسرے پراسیسز چل رہا ہے، یہ صرف یہ کہتا ہے کہ "جب میں مصروف ہوں، میں آپ کو وقت نہیں دے سکتا۔" KVM پر، اسٹیل کیلکولیشن کے لیے سپورٹ شامل کر دی گئی ہے۔ پیچ. یہاں دو اہم نکات ہیں:

  • ورچوئل مشین ہائپر وائزر سے چوری کے بارے میں سیکھتی ہے۔ یعنی نقصانات کے نقطہ نظر سے، ورچوئل مشین پر عمل کے لیے یہ ایک بالواسطہ پیمائش ہے جو مختلف تحریفات کا شکار ہو سکتی ہے۔
  • ہائپرائزر ورچوئل مشین کے ساتھ معلومات کا اشتراک نہیں کرتا ہے کہ یہ اور کیا کر رہا ہے - اہم بات یہ ہے کہ وہ اس کے لئے وقت نہیں دیتا ہے۔ اس کی وجہ سے، ورچوئل مشین خود چوری کے اشارے میں بگاڑ کا پتہ نہیں لگا سکتی، جس کا اندازہ مسابقتی عمل کی نوعیت سے لگایا جا سکتا ہے۔

2. چوری پر کیا اثر پڑتا ہے۔

2.1 حساب چوری کرنا

بنیادی طور پر، چوری کا حساب تقریباً عام سی پی یو کے استعمال کے وقت کے حساب سے کیا جاتا ہے۔ ری سائیکلنگ کو کس طرح سمجھا جاتا ہے اس کے بارے میں زیادہ معلومات نہیں ہیں۔ شاید اس لیے کہ زیادہ تر لوگ اس سوال کو واضح سمجھتے ہیں۔ لیکن یہاں بھی خرابیاں ہیں۔ اس عمل سے اپنے آپ کو واقف کرنے کے لیے، آپ پڑھ سکتے ہیں۔ برینڈن گریگ کا مضمون: آپ استعمال کا حساب لگاتے وقت بہت سی باریکیوں کے بارے میں اور ان حالات کے بارے میں جانیں گے جب یہ حساب درج ذیل وجوہات کی بنا پر غلط ہو جائے گا:

  • پروسیسر زیادہ گرم ہو جاتا ہے، جس کی وجہ سے سائیکل بند ہو جاتے ہیں۔
  • ٹربو بوسٹ کو فعال/غیر فعال کریں، جو پروسیسر کی گھڑی کی فریکوئنسی کو تبدیل کرتا ہے۔
  • وقت کے ٹکڑوں کی لمبائی میں تبدیلی جو پروسیسر پاور سیونگ ٹیکنالوجیز جیسے کہ SpeedStep استعمال کرتے وقت ہوتی ہے۔
  • اوسط کا حساب لگانے میں مسئلہ: 80% پر ایک منٹ کے استعمال کا تخمینہ لگانا 100% کے قلیل مدتی برسٹ کو چھپا سکتا ہے۔
  • اسپن لاک کی وجہ سے پروسیسر کو دوبارہ حاصل کیا جا سکتا ہے، لیکن صارف کے عمل کو اس کے عمل میں کوئی پیش رفت نظر نہیں آتی۔ نتیجے کے طور پر، عمل کے ذریعے حسابی پروسیسر کا استعمال سو فیصد ہو گا، حالانکہ یہ عمل جسمانی طور پر پروسیسر کا وقت استعمال نہیں کرے گا۔

مجھے کوئی مضمون نہیں ملا جس میں چوری کے لیے اسی طرح کے حساب کتاب کی وضاحت کی گئی ہو (اگر آپ جانتے ہیں تو تبصروں میں اس کا اشتراک کریں)۔ لیکن، سورس کوڈ کے مطابق، حساب کتاب کا طریقہ کار وہی ہے جو ری سائیکلنگ کے لیے ہے۔ بس، دانا میں ایک اور کاؤنٹر شامل کیا جاتا ہے، براہ راست KVM عمل (ورچوئل مشین پروسیس) کے لیے، جو CPU وقت کے انتظار میں KVM عمل کے دورانیے کو شمار کرتا ہے۔ کاؤنٹر اس کی تفصیلات سے پروسیسر کے بارے میں معلومات لیتا ہے اور چیک کرتا ہے کہ آیا اس کی تمام ٹِکس ورچوئل مشین کے عمل کے ذریعے استعمال کی گئی ہیں۔ اگر یہ سب کچھ ہے، تو ہم فرض کرتے ہیں کہ پروسیسر صرف ورچوئل مشین کے عمل میں شامل تھا۔ دوسری صورت میں، ہم مطلع کرتے ہیں کہ پروسیسر کچھ اور کر رہا تھا، چوری ظاہر ہوا.

چوری کی گنتی کا عمل انہی مسائل سے مشروط ہے جیسا کہ ری سائیکلنگ کی باقاعدہ گنتی۔ یہ کہنا نہیں ہے کہ اس طرح کے مسائل اکثر ظاہر ہوتے ہیں، لیکن وہ حوصلہ شکن نظر آتے ہیں.

2.2 KVM پر ورچوئلائزیشن کی اقسام

موٹے طور پر، ورچوئلائزیشن کی تین قسمیں ہیں، جن میں سے سبھی KVM کے ذریعے تعاون یافتہ ہیں۔ چوری ہونے کا طریقہ کار ورچوئلائزیشن کی قسم پر منحصر ہو سکتا ہے۔

نشریات. اس صورت میں، فزیکل ہائپر وائزر ڈیوائسز کے ساتھ ورچوئل مشین آپریٹنگ سسٹم کا آپریشن کچھ اس طرح ہوتا ہے:

  1. گیسٹ آپریٹنگ سسٹم اپنے گیسٹ ڈیوائس کو کمانڈ بھیجتا ہے۔
  2. گیسٹ ڈیوائس ڈرائیور کمانڈ وصول کرتا ہے، ڈیوائس BIOS کے لیے درخواست تیار کرتا ہے اور اسے ہائپر وائزر کو بھیجتا ہے۔
  3. ہائپر وائزر عمل فزیکل ڈیوائس کے لیے کمانڈ ٹو کمانڈ کا ترجمہ کرتا ہے، اسے دوسری چیزوں کے علاوہ، زیادہ محفوظ بناتا ہے۔
  4. فزیکل ڈیوائس ڈرائیور ترمیم شدہ کمانڈ کو قبول کرتا ہے اور اسے خود فزیکل ڈیوائس پر بھیجتا ہے۔
  5. کمانڈز پر عمل درآمد کے نتائج اسی راستے پر واپس آتے ہیں۔

ترجمہ کا فائدہ یہ ہے کہ یہ آپ کو کسی بھی ڈیوائس کی تقلید کرنے کی اجازت دیتا ہے اور آپریٹنگ سسٹم کے کرنل کی خصوصی تیاری کی ضرورت نہیں ہے۔ لیکن آپ کو اس کی قیمت ادا کرنی ہوگی، سب سے پہلے، رفتار میں۔

ہارڈ ویئر ورچوئلائزیشن. اس صورت میں، ہارڈ ویئر کی سطح پر ڈیوائس آپریٹنگ سسٹم کے کمانڈز کو سمجھتی ہے۔ یہ سب سے تیز اور بہترین طریقہ ہے۔ لیکن، بدقسمتی سے، یہ تمام فزیکل ڈیوائسز، ہائپر وائزرز اور گیسٹ آپریٹنگ سسٹم کے ذریعے تعاون یافتہ نہیں ہے۔ فی الحال، ہارڈویئر ورچوئلائزیشن کو سپورٹ کرنے والے اہم آلات پروسیسر ہیں۔

پیرا ورچوئلائزیشن. KVM پر ڈیوائس ورچوئلائزیشن کے لیے سب سے عام آپشن اور گیسٹ آپریٹنگ سسٹمز کے لیے عام طور پر سب سے عام ورچوئلائزیشن موڈ۔ اس کی خاصیت یہ ہے کہ کچھ ہائپر وائزر سب سسٹمز کے ساتھ کام کرنا (مثال کے طور پر نیٹ ورک یا ڈسک اسٹیک کے ساتھ) یا میموری پیجز کو مختص کرنا ہائپر وائزر API کا استعمال کرتے ہوئے، نچلے درجے کے کمانڈز کا ترجمہ کیے بغیر ہوتا ہے۔ اس ورچوئلائزیشن کے طریقہ کار کا نقصان یہ ہے کہ گیسٹ آپریٹنگ سسٹم کے کرنل میں ترمیم کی جانی چاہیے تاکہ یہ اس API کا استعمال کرتے ہوئے ہائپر وائزر کے ساتھ بات چیت کر سکے۔ لیکن یہ عام طور پر مہمان آپریٹنگ سسٹم پر خصوصی ڈرائیوروں کو انسٹال کرکے حل کیا جاتا ہے۔ KVM میں اس API کو کہا جاتا ہے۔ virtio API.

پیرا ورچوئلائزیشن کے ساتھ، براڈکاسٹنگ کے مقابلے، فزیکل ڈیوائس کا راستہ براہ راست ورچوئل مشین سے میزبان پر ہائپر وائزر پراسیس کو بھیجنے سے نمایاں طور پر کم ہو جاتا ہے۔ یہ آپ کو ورچوئل مشین کے اندر تمام ہدایات پر عمل درآمد کو تیز کرنے کی اجازت دیتا ہے۔ KVM میں، یہ virtio API کے ذریعے کیا جاتا ہے، جو صرف کچھ آلات کے لیے کام کرتا ہے، جیسے کہ نیٹ ورک یا ڈسک اڈاپٹر۔ یہی وجہ ہے کہ ورچوئل مشینوں کے اندر ورٹیو ڈرائیور نصب ہوتے ہیں۔

اس سرعت کا منفی پہلو یہ ہے کہ ورچوئل مشین کے اندر چلنے والے تمام عمل اس کے اندر نہیں رہتے ہیں۔ اس سے کچھ خاص اثرات پیدا ہوتے ہیں جن کے نتیجے میں چوری پر پھوٹ پڑ سکتی ہے۔ میں اس مسئلے کا تفصیلی مطالعہ شروع کرنے کی تجویز کرتا ہوں۔ ورچوئل I/O کے لیے ایک API: virtio.

2.3 "منصفانہ" شیڈولنگ

ہائپر وائزر پر ایک ورچوئل مشین درحقیقت ایک عام عمل ہے جو لینکس کرنل میں نظام الاوقات (عمل کے درمیان وسائل کی تقسیم) کے قوانین کی پابندی کرتا ہے، تو آئیے اس پر گہری نظر ڈالتے ہیں۔

لینکس نام نہاد CFS، مکمل طور پر منصفانہ شیڈیولر استعمال کرتا ہے، جو کرنل 2.6.23 کے بعد سے طے شدہ شیڈولر بن گیا ہے۔ اس الگورتھم کو سمجھنے کے لیے، آپ لینکس کرنل آرکیٹیکچر یا سورس کوڈ پڑھ سکتے ہیں۔ CFS کا جوہر یہ ہے کہ پروسیسر کے وقت کو عمل کے درمیان ان کے عمل کی مدت کے لحاظ سے تقسیم کیا جائے۔ ایک عمل کو جتنا زیادہ CPU وقت درکار ہوتا ہے، اتنا ہی کم CPU وقت اسے ملتا ہے۔ یہ اس بات کو یقینی بناتا ہے کہ تمام پراسیسز کو "منصفانہ" طور پر انجام دیا گیا ہے - تاکہ ایک عمل تمام پروسیسرز پر مستقل طور پر قبضہ نہ کرے، اور دوسرے عمل بھی عمل میں آسکتے ہیں۔

بعض اوقات یہ تمثیل دلچسپ نمونے کی طرف لے جاتی ہے۔ طویل عرصے سے لینکس استعمال کرنے والے شاید ڈیسک ٹاپ پر ریگولر ٹیکسٹ ایڈیٹر کا منجمد ہونا یاد رکھتے ہیں جب کہ کمپائلر جیسی وسائل سے متعلق ایپلی کیشنز چلاتے ہیں۔ ایسا اس لیے ہوا کیونکہ ڈیسک ٹاپ ایپلی کیشنز میں غیر وسائل سے متعلق کاموں کا مقابلہ وسائل سے متعلق کاموں سے ہوتا ہے، جیسے کمپائلر۔ CFS سوچتا ہے کہ یہ غیر منصفانہ ہے، لہذا یہ وقتاً فوقتاً ٹیکسٹ ایڈیٹر کو روکتا ہے اور پروسیسر کو کمپائلر کے کاموں کو سنبھالنے دیتا ہے۔ یہ ایک طریقہ کار کا استعمال کرتے ہوئے درست کیا گیا تھا sched_autogroup، لیکن کاموں کے درمیان پروسیسر کے وقت کی تقسیم کی بہت سی دوسری خصوصیات باقی ہیں۔ دراصل، یہ کہانی نہیں ہے کہ CFS میں سب کچھ کتنا خراب ہے، بلکہ اس حقیقت کی طرف توجہ دلانے کی کوشش ہے کہ پروسیسر کے وقت کی "منصفانہ" تقسیم سب سے معمولی کام نہیں ہے۔

شیڈولر میں ایک اور اہم نکتہ preemption ہے۔ پروسیسر سے ہنسنے کے عمل کو ختم کرنے اور دوسروں کو کام کرنے دینے کے لیے یہ ضروری ہے۔ اخراج کے عمل کو سیاق و سباق کی سوئچنگ کہا جاتا ہے۔ اس صورت میں، کام کا پورا سیاق و سباق محفوظ ہے: اسٹیک، رجسٹرز، وغیرہ کی حالت، جس کے بعد عمل کو انتظار کے لیے بھیجا جاتا ہے، اور اس کی جگہ ایک اور لے لیتا ہے۔ یہ OS کے لیے ایک مہنگا آپریشن ہے اور شاذ و نادر ہی استعمال ہوتا ہے، لیکن اس میں فطری طور پر کچھ بھی غلط نہیں ہے۔ بار بار سیاق و سباق کو تبدیل کرنا OS میں کسی مسئلے کی نشاندہی کر سکتا ہے، لیکن عام طور پر یہ مسلسل ہوتا ہے اور خاص طور پر کسی چیز کی نشاندہی نہیں کرتا ہے۔

ایک حقیقت کی وضاحت کے لیے اتنی لمبی کہانی کی ضرورت ہے: ایک پروسیسر کے وسائل کو ایک ایماندار لینکس شیڈیولر میں استعمال کرنے کی کوشش کی جائے گی، اسے اتنی ہی تیزی سے روکا جائے گا تاکہ دوسرے عمل بھی کام کر سکیں۔ آیا یہ درست ہے یا نہیں یہ ایک پیچیدہ سوال ہے جسے مختلف بوجھ کے تحت مختلف طریقے سے حل کیا جا سکتا ہے۔ ونڈوز میں، حال ہی میں، شیڈیولر ڈیسک ٹاپ ایپلی کیشنز کی ترجیحی پروسیسنگ پر توجہ مرکوز کرتا تھا، جو پس منظر کے عمل کو منجمد کرنے کا سبب بن سکتا ہے۔ سن سولارس کے پاس شیڈولرز کی پانچ مختلف کلاسیں تھیں۔ جب ہم نے ورچوئلائزیشن کا آغاز کیا، تو ہم نے چھٹا شامل کیا، منصفانہ شیئر شیڈولر، کیونکہ پچھلے پانچوں نے سولاریس زونز ورچوئلائزیشن کے ساتھ مناسب طریقے سے کام نہیں کیا۔ میں تجویز کرتا ہوں کہ اس مسئلے کا تفصیلی مطالعہ جیسے کتابوں سے شروع کریں۔ سولاریس انٹرنل: سولاریس 10 اور اوپن سولاریس کرنل آرکیٹیکچر یا لینکس کرنل کو سمجھنا.

2.4 چوری کی نگرانی کیسے کریں؟

کسی دوسرے پروسیسر میٹرک کی طرح، ورچوئل مشین کے اندر چوری کی نگرانی کرنا آسان ہے: آپ کسی بھی پروسیسر میٹرکس ٹول کا استعمال کر سکتے ہیں۔ اہم بات یہ ہے کہ ورچوئل مشین لینکس پر ہے۔ کسی وجہ سے ونڈوز اپنے صارفین کو یہ معلومات فراہم نہیں کرتا ہے۔ 🙁

چوری: جو ورچوئل مشینوں سے پروسیسر کا وقت چوری کرتا ہے۔
اوپری کمانڈ کا آؤٹ پٹ: پروسیسر لوڈ کی تفصیلات، سب سے دائیں کالم میں - چوری کریں۔

ہائیپرائزر سے یہ معلومات حاصل کرنے کی کوشش کرتے وقت مشکل پیدا ہوتی ہے۔ آپ میزبان مشین پر چوری کی پیشن گوئی کرنے کی کوشش کر سکتے ہیں، مثال کے طور پر، لوڈ ایوریج (LA) پیرامیٹر کا استعمال کرتے ہوئے - عمل درآمد کی قطار میں انتظار کر رہے عمل کی تعداد کی اوسط قدر۔ اس پیرامیٹر کا حساب لگانے کا طریقہ آسان نہیں ہے، لیکن عام طور پر، اگر LA کو پروسیسر کے دھاگوں کی تعداد سے نارمل کیا جائے تو 1 سے زیادہ ہے، یہ اس بات کی نشاندہی کرتا ہے کہ لینکس سرور کسی چیز سے بھرا ہوا ہے۔

یہ تمام عمل کس چیز کا انتظار کر رہے ہیں؟ واضح جواب پروسیسر ہے۔ لیکن جواب مکمل طور پر درست نہیں ہے، کیونکہ بعض اوقات پروسیسر مفت ہوتا ہے، لیکن ایل اے پیمانے سے ہٹ جاتا ہے۔ یاد رکھیں NFS کیسے گرتا ہے اور LA کیسے بڑھتا ہے۔. ڈسک اور دیگر ان پٹ/آؤٹ پٹ آلات کے ساتھ بھی ایسا ہی ہو سکتا ہے۔ لیکن درحقیقت، عمل کسی بھی تالے کے اختتام کا انتظار کر سکتے ہیں، یا تو جسمانی، I/O ڈیوائس سے منسلک، یا منطقی، جیسے کہ mutex۔ اس میں ہارڈ ویئر کی سطح پر تالا لگانا بھی شامل ہے (ڈسک سے وہی جواب)، یا منطق (نام نہاد لاکنگ پرائمیٹوز، جس میں ہستیوں کا ایک گروپ، mutex adaptive اور spin، سیمفورس، حالت متغیرات، rw locks، ipc locks شامل ہیں۔ ...)۔

ایل اے کی ایک اور خصوصیت یہ ہے کہ اسے آپریٹنگ سسٹم اوسط سمجھا جاتا ہے۔ مثال کے طور پر، 100 عمل ایک فائل کے لیے مقابلہ کر رہے ہیں، اور پھر LA=50۔ اتنی بڑی قدر اس بات کی نشاندہی کرتی ہے کہ آپریٹنگ سسٹم خراب ہے۔ لیکن دوسرے ٹیڑھے لکھے ہوئے کوڈ کے لیے، یہ ایک عام حالت ہو سکتی ہے، اس حقیقت کے باوجود کہ یہ صرف خراب ہے، اور آپریٹنگ سسٹم میں دیگر عمل متاثر نہیں ہوتے ہیں۔

اس اوسط کی وجہ سے (اور ایک منٹ سے بھی کم وقت میں)، LA اشارے کے ذریعہ کسی بھی چیز کا تعین کرنا سب سے زیادہ فائدہ مند کام نہیں ہے، خاص معاملات میں بہت غیر یقینی نتائج کے ساتھ۔ اگر آپ اسے معلوم کرنے کی کوشش کرتے ہیں، تو آپ کو معلوم ہوگا کہ ویکیپیڈیا اور دیگر دستیاب وسائل پر موجود مضامین اس عمل کی گہرائی سے وضاحت کے بغیر صرف سادہ ترین معاملات کو بیان کرتے ہیں۔ میں ہر ایک کو بھیجتا ہوں جو دلچسپی رکھتا ہے، دوبارہ، یہاں برینڈن گریگ کے پاس  - نیچے دیئے گئے لنکس پر عمل کریں۔ جو انگریزی بولنے میں بہت سست ہے - ایل اے کے بارے میں ان کے مشہور مضمون کا ترجمہ.

3. خصوصی اثرات

اب آئیے چوری کے اہم کیسز کو دیکھتے ہیں جن کا ہم نے سامنا کیا۔ میں آپ کو بتاؤں گا کہ وہ مندرجہ بالا سبھی چیزوں کی پیروی کیسے کرتے ہیں اور وہ ہائپر وائزر کے اشارے سے کیسے متعلق ہیں۔

ری سائیکلنگ. سب سے آسان اور عام: ہائپر وائزر کو دوبارہ استعمال کیا گیا ہے۔ درحقیقت، بہت ساری ورچوئل مشینیں چل رہی ہیں، ان کے اندر پروسیسر کی زیادہ کھپت ہے، بہت زیادہ مقابلہ ہے، LA کا استعمال 1 سے زیادہ ہے (پروسیسر کے دھاگوں سے معمول کے مطابق)۔ تمام ورچوئل مشینوں کے اندر سب کچھ سست ہو جاتا ہے۔ ہائپرائزر سے منتقل ہونے والی چوری بھی بڑھ رہی ہے، یہ لوڈ کو دوبارہ تقسیم کرنے یا کسی کو بند کرنے کے لئے ضروری ہے. عام طور پر، سب کچھ منطقی اور قابل فہم ہے.

پیرا ورچوئلائزیشن بمقابلہ سنگل مثالیں۔. ہائپر وائزر پر صرف ایک ورچوئل مشین ہے؛ یہ اس کا ایک چھوٹا حصہ کھاتی ہے، لیکن ایک بڑا I/O بوجھ پیدا کرتی ہے، مثال کے طور پر ڈسک پر۔ اور کہیں سے اس میں ایک چھوٹی سی چوری نظر آتی ہے، 10% تک (جیسا کہ کئی تجربات سے دکھایا گیا ہے)۔

معاملہ دلچسپ ہے۔ پیرا ورچوئلائزڈ ڈرائیورز کی سطح پر مسدود ہونے کی وجہ سے چوری یہاں واضح طور پر ظاہر ہوتی ہے۔ ورچوئل مشین کے اندر ایک رکاوٹ پیدا ہوتی ہے، جس پر ڈرائیور کے ذریعے کارروائی کی جاتی ہے اور ہائپر وائزر کو بھیجا جاتا ہے۔ ہائپر وائزر پر رکاوٹ ہینڈلنگ کی وجہ سے، ورچوئل مشین کے لیے یہ ایک بھیجی گئی درخواست کی طرح لگتا ہے، یہ عملدرآمد کے لیے تیار ہے اور پروسیسر کا انتظار کر رہا ہے، لیکن اسے پروسیسر کا وقت نہیں دیا گیا ہے۔ مجازی لڑکی سمجھتی ہے کہ یہ وقت چوری ہو گیا ہے۔

یہ اس وقت ہوتا ہے جب بفر بھیجا جاتا ہے، یہ ہائپر وائزر کے کرنل اسپیس میں چلا جاتا ہے، اور ہم اس کا انتظار کرنا شروع کر دیتے ہیں۔ اگرچہ، مجازی مشین کے نقطہ نظر سے، اسے فوری طور پر واپس آنا چاہئے. لہذا، اسٹیل کیلکولیشن الگورتھم کے مطابق، اس وقت کو چوری سمجھا جاتا ہے۔ زیادہ تر امکان ہے، اس صورت حال میں دیگر میکانزم ہو سکتے ہیں (مثال کے طور پر، کچھ دوسرے sys کالوں پر کارروائی کرنا)، لیکن وہ زیادہ مختلف نہیں ہونے چاہئیں۔

شیڈیولر بمقابلہ انتہائی بھری ہوئی ورچوئل مشینیں۔. جب ایک ورچوئل مشین دوسروں کے مقابلے میں زیادہ چوری کا شکار ہوتی ہے، تو یہ شیڈیولر کی وجہ سے ہوتا ہے۔ ایک عمل جتنا زیادہ پروسیسر کو لوڈ کرے گا، شیڈولر اتنی ہی جلدی اسے باہر نکال دے گا تاکہ دوسرے بھی کام کر سکیں۔ اگر ورچوئل مشین بہت کم استعمال کرتی ہے، تو اسے شاید ہی چوری نظر آئے گی: اس کا عمل ایمانداری سے بیٹھ کر انتظار کرتا رہا، ہمیں اسے مزید وقت دینے کی ضرورت ہے۔ اگر کوئی ورچوئل مشین اپنے تمام کور پر زیادہ سے زیادہ بوجھ پیدا کرتی ہے، تو اسے اکثر پروسیسر سے باہر نکال دیا جاتا ہے اور وہ کوشش کرتے ہیں کہ اسے زیادہ وقت نہ دیں۔

یہ اور بھی برا ہوتا ہے جب ورچوئل مشین کے اندر موجود عمل زیادہ پروسیسر حاصل کرنے کی کوشش کرتے ہیں کیونکہ وہ ڈیٹا پروسیسنگ کا مقابلہ نہیں کر سکتے۔ پھر ہائپر وائزر پر آپریٹنگ سسٹم، ایماندارانہ اصلاح کی وجہ سے، کم سے کم پروسیسر کا وقت فراہم کرے گا۔ یہ عمل برفانی تودے کی طرح ہوتا ہے، اور آسمان پر چھلانگیں چوری کرتا ہے، حالانکہ دوسری ورچوئل مشینیں شاید ہی اسے محسوس کرتی ہیں۔ اور جتنے زیادہ کور، متاثرہ مشین اتنی ہی خراب۔ مختصر یہ کہ بہت سے کور کے ساتھ انتہائی بھری ہوئی ورچوئل مشینیں سب سے زیادہ متاثر ہوتی ہیں۔

کم LA، لیکن وہاں چوری ہے. اگر LA تقریباً 0,7 ہے (یعنی ایسا لگتا ہے کہ ہائپر وائزر انڈر لوڈ ہوا ہے)، لیکن انفرادی ورچوئل مشینوں کے اندر چوری کا مشاہدہ کیا جاتا ہے:

  • پیرا ورچوئلائزیشن والا آپشن پہلے ہی اوپر بیان کیا گیا ہے۔ ورچوئل مشین چوری کی نشاندہی کرنے والے میٹرکس وصول کر سکتی ہے، حالانکہ ہائپر وائزر ٹھیک ہے۔ ہمارے تجربات کے نتائج کے مطابق، یہ اسٹیل آپشن 10% سے زیادہ نہیں ہے اور اس کا ورچوئل مشین کے اندر ایپلی کیشنز کی کارکردگی پر کوئی خاص اثر نہیں ہونا چاہیے۔
  • ایل اے پیرامیٹر کا حساب غلط لگایا گیا ہے۔ مزید واضح طور پر، ہر مخصوص لمحے پر اس کا صحیح حساب لگایا جاتا ہے، لیکن جب ایک منٹ سے زیادہ کا اوسط لیا جائے تو یہ کم اندازہ لگایا جاتا ہے۔ مثال کے طور پر، اگر ایک ورچوئل مشین فی تہائی ہائپر وائزر اپنے تمام پروسیسرز کو بالکل آدھے منٹ کے لیے استعمال کرتی ہے، تو ہائپر وائزر پر LA فی منٹ 0,15 ہوگا۔ ایک ساتھ کام کرنے والی چار ایسی ورچوئل مشینیں 0,6 دیں گی۔ اور حقیقت یہ ہے کہ ان میں سے ہر ایک پر آدھے منٹ کے لئے LA اشارے کے مطابق 25٪ پر جنگلی چوری تھی اب اسے باہر نہیں نکالا جا سکتا۔
  • ایک بار پھر، شیڈولر کی وجہ سے جس نے فیصلہ کیا کہ کوئی بہت زیادہ کھا رہا ہے اور کسی کو انتظار کرنے دو۔ اس دوران، میں سیاق و سباق کو تبدیل کروں گا، رکاوٹوں کو ہینڈل کروں گا اور سسٹم کی دیگر اہم چیزوں کا خیال رکھوں گا۔ نتیجے کے طور پر، کچھ ورچوئل مشینوں کو کوئی مسئلہ نظر نہیں آتا، جبکہ دیگر کو کارکردگی میں شدید کمی کا سامنا کرنا پڑتا ہے۔

4. دیگر تحریفات

ورچوئل مشین پر پروسیسر کے وقت کی منصفانہ واپسی کو مسخ کرنے کی مزید دس لاکھ وجوہات ہیں۔ مثال کے طور پر، ہائپر تھریڈنگ اور NUMA حساب میں مشکلات پیش کرتے ہیں۔ وہ عمل کو انجام دینے کے لیے دانا کے انتخاب کو مکمل طور پر الجھا دیتے ہیں، کیونکہ شیڈولر گتانکوں - وزنوں کا استعمال کرتا ہے، جو سیاق و سباق کو تبدیل کرتے وقت حساب کو مزید مشکل بنا دیتا ہے۔

ٹربو بوسٹ یا اس کے برعکس انرجی سیونگ موڈ جیسی ٹیکنالوجیز کی وجہ سے بگاڑ پیدا ہوتا ہے، جو کہ استعمال کا حساب لگاتے وقت مصنوعی طور پر فریکوئنسی یا سرور پر ٹائم سلائس کو بڑھا یا گھٹا سکتا ہے۔ ٹربو بوسٹ کو فعال کرنے سے ایک پروسیسر تھریڈ کی کارکردگی دوسرے کی کارکردگی میں اضافے کی وجہ سے کم ہو جاتی ہے۔ اس وقت، موجودہ پروسیسر کی فریکوئنسی کے بارے میں معلومات ورچوئل مشین کو منتقل نہیں کی جاتی ہے، اور اس کا خیال ہے کہ کوئی اس کا وقت چوری کر رہا ہے (مثال کے طور پر، اس نے 2 گیگا ہرٹز کی درخواست کی، لیکن اس سے نصف موصول ہوا)۔

عام طور پر، تحریف کی بہت سی وجوہات ہو سکتی ہیں۔ آپ کو کسی خاص سسٹم پر کچھ اور مل سکتا ہے۔ ان کتابوں سے شروع کرنا بہتر ہے جن کے لنکس میں نے اوپر دیے ہیں، اور ہائپر وائزر سے اعدادوشمار کو بازیافت کرنا جیسے کہ perf، sysdig، systemtap جیسی افادیت کا استعمال کرتے ہوئے درجن.

5. نتائج

  1. پیرا ورچوئلائزیشن کی وجہ سے چوری کی کچھ مقدار ہو سکتی ہے، اور اسے عام سمجھا جا سکتا ہے۔ وہ انٹرنیٹ پر لکھتے ہیں کہ یہ قدر 5-10% ہو سکتی ہے۔ ورچوئل مشین کے اندر موجود ایپلی کیشنز اور اس کے جسمانی آلات پر بوجھ ڈالنے پر منحصر ہے۔ یہاں پر توجہ دینا ضروری ہے کہ ایپلی کیشنز ورچوئل مشینوں کے اندر کیسا محسوس کرتی ہیں۔
  2. ہائپر وائزر پر بوجھ اور ورچوئل مشین کے اندر چوری کا تناسب ہمیشہ واضح طور پر باہم منسلک نہیں ہوتا؛ چوری کے دونوں اندازے مختلف بوجھ کے تحت مخصوص حالات میں غلط ہو سکتے ہیں۔
  3. شیڈولر کا ان عملوں کے بارے میں برا رویہ ہے جو بہت کچھ پوچھتے ہیں۔ زیادہ مانگنے والوں کو کم دینے کی کوشش کرتا ہے۔ بڑی ورچوئل مشینیں بری ہیں۔
  4. پیرا ورچوئلائزیشن کے بغیر بھی تھوڑی سی چوری معمول بن سکتی ہے (ورچوئل مشین کے اندر بوجھ، پڑوسیوں کے بوجھ کی خصوصیات، دھاگوں میں لوڈ کی تقسیم اور دیگر عوامل کو مدنظر رکھتے ہوئے)۔
  5. اگر آپ کسی مخصوص سسٹم میں چوری کا پتہ لگانا چاہتے ہیں تو آپ کو مختلف آپشنز کو تلاش کرنا ہوگا، میٹرکس جمع کرنا ہوں گے، ان کا بغور تجزیہ کرنا ہوگا اور بوجھ کو یکساں طور پر تقسیم کرنے کے بارے میں سوچنا ہوگا۔ کسی بھی صورت سے انحراف ممکن ہے، جس کی تجرباتی طور پر تصدیق کی جانی چاہیے یا کرنل ڈیبگر میں دیکھنا چاہیے۔

ماخذ: www.habr.com

نیا تبصرہ شامل کریں