نظام میں منتخب کردہ ٹائم سورس کی کارکردگی کے اثرات کا تجزیہ

برینڈن گریگ، DTrace کے ڈویلپرز میں سے ایک، جو اس وقت لینکس کرنل میں BPF پر مبنی کارکردگی کے تجزیہ کے ٹولز تیار کر رہے ہیں، نے کارکردگی کے ان مسائل کا تجزیہ کرنے سے حاصل ہونے والے تجربے کا خلاصہ کیا جو Netflix کو Cassandra DBMS کو CentOS سے Ubuntu منتقل کرنے کے دوران پیش آئے۔ Xen پر مبنی Amazon EC2 کلاؤڈ۔ منتقلی کے بعد، CPU بوجھ میں 30% اضافہ ہوا اور تحریری کارروائیوں کے دوران تاخیر میں تقریباً اسی مقدار میں اضافہ ہوا۔ جیسا کہ یہ پتہ چلتا ہے، ایپلی کیشنز کی کارکردگی جو بہت زیادہ وقت کی معلومات کی درخواست کرتی ہے اس کا انحصار سسٹم میں منتخب کردہ صحیح وقت کے ذریعہ پر ہوتا ہے۔

سب سے پہلے، کارکردگی میں کمی کی وجہ واضح نہیں تھی اور تشخیص کا آغاز ٹاپ اور execsnoop یوٹیلیٹیز کا استعمال کرتے ہوئے مسلسل چلانے یا وقتاً فوقتاً شروع کیے جانے والے وسائل سے متعلق نظام کے ممکنہ اثرات کی نگرانی سے ہوا۔ لیکن ہر چیز نے اشارہ کیا کہ وسائل کی کھپت میں خاص طور پر جاوا میں لکھے گئے کیسنڈرا ڈی بی ایم ایس میں اضافہ ہوا ہے۔ CentOS اور Ubuntu پر متوازی طور پر چلنے والے دو Cassandra پروسیسز کی پروفائلنگ میٹرکس کا موازنہ کرتے ہوئے، ایک ہی سوالات پر کارروائی کرتے ہوئے، ظاہر ہوا کہ کل وقت کا تقریباً 32% os::javaTimeMillis() پر کال کرنے میں صرف ہوا، جو موجودہ وقت کے بارے میں معلومات حاصل کرنے کے لیے استعمال ہوتا ہے۔ .

اس کے بعد ایک تجربہ کیا گیا جس میں جاوا کی ایک سادہ ایپلیکیشن لکھی گئی جسے System.currentTimeMillis() طریقہ کہا جاتا ہے ایک سو ملین بار ایک لوپ میں۔ ایپلی کیشن کو چلانے سے ظاہر ہوا کہ اسے CentOS پر مکمل ہونے میں 13 سیکنڈ لگے، اور Ubuntu پر تقریباً 68 سیکنڈ، یعنی 5 گنا سست۔ اسی طرح کا ایک پروگرام C میں لکھا گیا جس نے gettimeofday() فنکشن کو سو ملین بار کہا، لیکن جب اس پر عمل کیا گیا تو اسی طرح کے نتائج برآمد ہوئے۔

چونکہ یہ واضح ہو گیا کہ مسئلہ کا ماخذ موجودہ وقت کو واپس کرنے کا کام تھا، اس لیے نظام میں درست وقت کے مختلف ذرائع کا انتخاب کرتے وقت اشارے میں تبدیلیوں پر توجہ دی گئی۔ "/sys/devices/system/clocksource/clocksource0/current_clocksource" کے مواد کو دیکھتے ہوئے، "xen" ٹائمر بطور ڈیفالٹ استعمال کیا جاتا تھا جب گیسٹ سسٹم میں لینکس چلاتے تھے۔ ٹائم سورس کو "tsc" میں تبدیل کرنے کے بعد، Ubuntu میں ٹیسٹ ایپلیکیشن کے عمل درآمد کا وقت 68 سے کم ہو کر 3.3 سیکنڈ ہو گیا، یعنی یہ 20 گنا تیز ہو گیا. مزید برآں، kvm-کلاک ٹائم سورس کا پرفارمنس ٹیسٹ کیا گیا، جس نے TSC کے مقابلے میں 20% تاخیر میں اضافہ دکھایا۔ $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $time java TimeBench اصلی 1m8.300s صارف 0m38.337. echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $time java TimeBench اصلی 29.875m0s صارف 0m3.370s sys 0m3.353s

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

Netflix پر پروڈکشن سرورز کو TSC سورس میں تبدیل کرنے کے نتیجے میں تحریری تاخیر میں 43% کمی واقع ہوئی اور Ubuntu کا استعمال کرتے ہوئے ایسے نتائج حاصل ہوئے جو CentOS کو "xen" ٹائم سورس کے ساتھ چلانے والی کنفیگریشنز سے 4 گنا تیز تھے۔ مطالعہ کے نتائج کو ایمیزون پر منتقل کر دیا گیا، جس نے Xen ہائپر وائزر کی بنیاد پر AWS EC2 ماحول میں پہلے سے طے شدہ TSC ٹائم سورس استعمال کرنے کی باضابطہ سفارش کی (Kvm-گھڑی نائٹرو ہائپر وائزر پر مبنی ماحول میں تجویز کی جاتی ہے)۔

ماخذ: opennet.ru