برینډن ګریګ ، د DTrace یو له پراختیا کونکو څخه ، چې دا مهال د لینکس کرنل کې د BPF پراساس د فعالیت تحلیلي وسیلې رامینځته کوي ، د فعالیت ستونزو تحلیل کولو څخه ترلاسه شوې تجربې لنډیز کوي چې Netflix ورسره مخ شو کله چې د Cassandra DBMS له CentOS څخه Ubuntu ته مهاجرت پر مهال. د ایمیزون EC2 بادل د Xen پر بنسټ. د مهاجرت څخه وروسته، د CPU بار 30٪ ډیر شوی او د لیکلو عملیاتو په جریان کې ځنډ د ورته مقدار څخه ډیر شوی. لکه څنګه چې دا معلومه شوه، د غوښتنلیکونو فعالیت چې په کلکه د وخت معلوماتو غوښتنه کوي په سیسټم کې د ټاکل شوي دقیق وخت سرچینې پورې اړه لري.
په لومړي سر کې، د فعالیت د کمښت لامل څرګند نه و او تشخیص د لوړ او execsnoop اسانتیاوو په کارولو سره د دوامداره چلولو یا په دوره توګه پیل شوي د سرچینو - ژور سیسټم پروسې احتمالي اغیزې څارلو سره پیل شو. مګر هرڅه په ګوته کوي چې د سرچینو مصرف په ځانګړي ډول په جاوا کې لیکل شوي کاسندرا DBMS کې ډیر شوی. په CentOS او Ubuntu کې په موازي ډول د دوه کاسندرا پروسو د پروفایل کولو میټریکونو پرتله کول، د ورته پوښتنو پروسس کول، په ډاګه کړه چې د ټول وخت شاوخوا 32٪ د os::javaTimeMillis() په زنګ وهلو لګول شوي، کوم چې د اوسني وخت په اړه د معلوماتو ترلاسه کولو لپاره کارول کیږي. .
له دې وروسته، یوه تجربه ترسره شوه چې په کې یو ساده جاوا اپلیکیشن لیکل شوی و چې د System.currentTimeMillis() میتود په نوم یادیږي سل ملیونه ځله په لوپ کې. د غوښتنلیک چلول وښودله چې په CentOS کې بشپړولو لپاره 13 ثانیې وخت نیسي، او په اوبنټو کې شاوخوا 68 ثانیې، د بیلګې په توګه. 5 ځله ورو. ورته برنامه په C کې لیکل شوې وه چې د gettimeofday() فنکشن سل ملیون ځله په نوم یادیږي ، مګر کله چې اجرا شي ، ورته پایلې ترلاسه شوې.
له هغه وخته چې دا څرګنده شوه چې د ستونزې سرچینه د اوسني وخت بیرته راستنیدل و، پاملرنه د شاخصونو بدلونونو ته واړول کله چې په سیسټم کې د دقیق وخت مختلف سرچینې غوره کول. د "/sys/devices/system/clocksource/clocksource0/current_clocksource" منځپانګې په پام کې نیولو سره، د "xen" ټایمر د ډیفالټ په واسطه کارول کیده کله چې په میلمستون کې لینکس چلول. د وخت سرچینې "tsc" ته بدلولو وروسته، په اوبنټو کې د ازموینې غوښتنلیک اجرا کولو وخت له 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 $ وخت جاوا TimeBench ریښتیني 1m8.300s کارن 0s38.337$. echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $time جاوا TimeBench اصلی 29.875m0s کارن 0m3.370s sys 0m3.353s
د وخت ترلاسه کولو لپاره کله چې د TSC سرچینې غوره کړئ، د RDTSC پروسیسر لارښوونې کارول کیږي، چې د هغې پلي کول د سیسټم کال ته اړتیا نلري (لارښوونه لوړ امتیازاتو ته اړتیا نلري او په CPU کې د جوړ شوي وخت کاونټر څخه ارزښت تولیدوي). د ډیفالټ په واسطه، TSC فعال نه دی ځکه چې په پخوانیو ورځو کې دا سرچینه د تدریجي وخت جریان نه خارجوي، کوم چې په نورو پروسیسرونو کې د سافټویر لخوا تنظیم شوي ترڅو دقیق لوستل ترلاسه کړي. د یو انجنیر په وینا چې د پروسیسر پراختیا کې تخصص لري، د TSC کارولو په وخت کې د وخت د بدلون په اړه ویره له اوږدې مودې راهیسې ناسمه وه او په عصري پروسیسرونو کې دا سرچینه کولی شي د کلونو لپاره مستحکم لوستل تولید کړي.
په Netflix کې د TSC سرچینې ته د تولید سرورونو بدلول په پایله کې د لیکلو ځنډ کې د 43٪ کمښت لامل شوی او د اوبنټو په کارولو سره یې پایلې ترلاسه کړې چې د "xen" وخت سرچینې سره د CentOS چلولو ترتیبونو څخه 4 ځله ګړندي وې. د مطالعې پایلې ایمیزون ته لیږدول شوي، کوم چې په رسمي توګه د AWS EC2 چاپیریالونو کې د Xen هایپروایسر پراساس د ډیفالټ TSC وخت سرچینې کارولو وړاندیز کړی (kvm-کلاک د نایټرو هایپروایزر پراساس په چاپیریال کې سپارښتنه پاتې کیږي).
سرچینه: opennet.ru