برينڊن گريگ، DTrace جي ڊولپرز مان هڪ، جيڪو هن وقت لينڪس ڪرنل ۾ BPF جي بنياد تي ڪارڪردگي تجزيي جا اوزار ٺاهي رهيو آهي، ڪارڪردگي جي مسئلن جو تجزيو ڪرڻ مان حاصل ڪيل تجربو جو خلاصو ڪيو جيڪو Netflix کي سامهون آيو جڏهن Cassandra DBMS کي CentOS کان Ubuntu ڏانهن منتقل ڪيو ويو. Amazon EC2 بادل Xen تي ٻڌل آهي. لڏپلاڻ کان پوء، سي پي يو لوڊ 30٪ کان وڌي ويو ۽ لکڻ جي عملن دوران دير سان ساڳئي رقم وڌي وئي. جيئن ته اهو نڪتو، ايپليڪيشنن جي ڪارڪردگي جيڪي شدت سان وقت جي معلومات جي درخواست ڪن ٿا، سسٽم ۾ چونڊيل صحيح وقت جي ذريعن تي منحصر آهي.
شروعات ۾، ڪارڪردگي ۾ گهٽتائي جو سبب واضح نه هو ۽ تشخيص مسلسل هلندڙ يا وقتي طور تي شروع ٿيندڙ وسيلن جي شدت واري نظام جي عملن جي ممڪن اثر جي نگراني سان شروع ٿي مٿين ۽ execsnoop افاديت استعمال ڪندي. پر هر شي ظاهر ڪيو ته وسيلن جو استعمال خاص طور تي Cassandra DBMS ۾ وڌي چڪو هو، جاوا ۾ لکيل آهي. CentOS ۽ Ubuntu تي متوازي طور تي هلندڙ ٻن Cassandra پروسيس جي پروفائيلنگ ميٽرڪس جو مقابلو ڪندي، ساڳئي سوالن کي پروسيس ڪندي، ظاهر ڪيو ته ڪل وقت جو تقريباً 32٪ os::javaTimeMillis() کي ڪال ڪندي خرچ ڪيو ويو، جيڪو موجوده وقت بابت معلومات حاصل ڪرڻ لاءِ استعمال ڪيو ويندو آهي. .
ان کان پوء، هڪ تجربو ڪيو ويو جنهن ۾ هڪ سادي جاوا ايپليڪيشن لکيو ويو جنهن کي System.currentTimeMillis() طريقو سڏيو ويندو آهي هڪ لک ۾ هڪ لک ڀيرا. ايپليڪيشن کي هلائڻ ڏيکاريو ته اهو CentOS تي مڪمل ٿيڻ ۾ 13 سيڪنڊن جو، ۽ Ubuntu تي اٽڪل 68 سيڪنڊ، يعني. 5 ڀيرا سست. هڪ اهڙو پروگرام سي ۾ لکيو ويو جنهن کي gettimeofday() فنڪشن سڏيو ويو سو ملين ڀيرا، پر جڏهن عمل ڪيو ويو، ساڳيا نتيجا حاصل ڪيا ويا.
جيئن ته اهو واضح ٿي ويو آهي ته مسئلي جو ذريعو موجوده وقت کي واپس ڪرڻ جو ڪم هو، سسٽم ۾ صحيح وقت جي مختلف ذريعن کي چونڊڻ دوران اشارن ۾ تبديلين ڏانهن ڌيان ڏنو ويو. "/sys/devices/system/clocksource/clocksource0/current_clocksource،" جي مواد جي لحاظ کان فيصلو ڪندي، "xen" ٽائمر ڊفالٽ طور استعمال ڪيو ويو جڏھن لينڪس کي مھمانن جي سسٽم ۾ ھلايو ويو. وقت جي ماخذ کي "tsc" ۾ تبديل ڪرڻ کان پوء، Ubuntu ۾ ٽيسٽ ايپليڪيشن جي عمل جو وقت 68 کان 3.3 سيڪنڊن تائين گھٽجي ويو، يعني. اهو 20 ڀيرا تيز ٿي ويو. اضافي طور تي، kvm-ڪلاڪ ٽائيم ماخذ جي ڪارڪردگي جو امتحان ڪيو ويو، جيڪو ڏيکاريو ويو تاخير ۾ 20٪ جي ڀيٽ ۾ TSC جي ڀيٽ ۾. $ 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 پروسيسر هدايتون استعمال ڪيون وينديون آهن، جنهن تي عمل ڪرڻ لاءِ سسٽم ڪال جي ضرورت نه هوندي آهي (هدايتن کي اعليٰ مراعات جي ضرورت نه هوندي آهي ۽ سي پي يو ۾ ٺهيل ٽائيم ڪائونٽر مان هڪ قدر پيدا ڪري ٿي). ڊفالٽ طور، TSC چالو نه ڪيو ويو آهي ڇاڪاڻ ته پراڻي ڏينهن ۾ هي ذريعو بتدريج وقت جي وهڪري کي خارج نه ڪيو ويو آهي، جيڪو ٻين پروسيسرز ۾ وڌيڪ صحيح پڙهڻ حاصل ڪرڻ لاء سافٽ ويئر طرفان ترتيب ڏنل آهي. پروسيسر ڊولپمينٽ ۾ ماهر هڪ انجنيئر جي مطابق، TSC استعمال ڪرڻ وقت وقت جي شفٽ جي باري ۾ خوف ڊگهي عرصي کان غلط آهي ۽ جديد پروسيسرز ۾ اهو ذريعو سالن تائين مستحڪم پڙهائي پيدا ڪري سگهي ٿو.
Netflix تي پروڊڪشن سرورز کي TSC ماخذ تي تبديل ڪرڻ جي نتيجي ۾ لکڻ جي دير ۾ 43٪ گهٽتائي ۽ Ubuntu استعمال ڪندي نتيجا حاصل ڪيا جيڪي "xen" وقت جي ماخذ سان CentOS تي هلندڙ ترتيبن کان 4 ڀيرا تيز هئا. مطالعي جا نتيجا Amazon ڏانهن منتقل ڪيا ويا، جن کي سرڪاري طور تي AWS EC2 ماحول ۾ ڊفالٽ TSC ٽائيم ماخذ استعمال ڪرڻ جي سفارش ڪئي وئي Xen hypervisor جي بنياد تي (kvm-clock جي سفارش ڪئي وئي ماحول ۾ Nitro hypervisor جي بنياد تي).
جو ذريعو: opennet.ru