ការវិភាគលើផលប៉ះពាល់នៃដំណើរការនៃប្រភពពេលវេលាដែលបានជ្រើសរើសនៅក្នុងប្រព័ន្ធ

Brendan Gregg អ្នកអភិវឌ្ឍន៍ម្នាក់នៃ DTrace ដែលបច្ចុប្បន្នកំពុងបង្កើតឧបករណ៍វិភាគការអនុវត្តផ្អែកលើ BPF នៅក្នុងខឺណែលលីនុច បានសង្ខេបបទពិសោធន៍ដែលទទួលបានពីការវិភាគបញ្ហាដំណើរការដែល Netflix ជួបប្រទះនៅពេលផ្ទេរ Cassandra DBMS ពី CentOS ទៅ Ubuntu ។ ពពក Amazon EC2 ផ្អែកលើ Xen ។ បន្ទាប់ពីការធ្វើចំណាកស្រុក ការផ្ទុកស៊ីភីយូកើនឡើង 30% ហើយការពន្យារពេលក្នុងអំឡុងពេលប្រតិបត្តិការសរសេរកើនឡើងប្រហែលចំនួនដូចគ្នា។ ដូចដែលវាប្រែថាការអនុវត្តនៃកម្មវិធីដែលស្នើសុំព័ត៌មានពេលវេលាយ៉ាងខ្លាំងអាស្រ័យលើប្រភពពេលវេលាពិតប្រាកដដែលបានជ្រើសរើសនៅក្នុងប្រព័ន្ធ។

ដំបូងឡើយ ហេតុផលសម្រាប់ការថយចុះនៃការអនុវត្តគឺមិនច្បាស់ទេ ហើយការធ្វើរោគវិនិច្ឆ័យបានចាប់ផ្តើមជាមួយនឹងការត្រួតពិនិត្យផលប៉ះពាល់ដែលអាចកើតមាននៃការដំណើរការឥតឈប់ឈរ ឬដំណើរការប្រព័ន្ធដែលពឹងផ្អែកលើធនធានដោយទៀងទាត់ដោយប្រើឧបករណ៍ប្រើប្រាស់កំពូល និង execsnoop ។ ប៉ុន្តែអ្វីគ្រប់យ៉ាងបានបង្ហាញថាការប្រើប្រាស់ធនធានបានកើនឡើងជាពិសេសនៅក្នុង Cassandra DBMS ដែលសរសេរជាភាសាចាវ៉ា។ ការប្រៀបធៀបរង្វាស់ទម្រង់នៃដំណើរការ Cassandra ពីរដែលកំពុងដំណើរការស្របគ្នានៅលើ CentOS និង Ubuntu ដែលដំណើរការសំណួរដូចគ្នាបានបង្ហាញថាប្រហែល 32% នៃពេលវេលាសរុបត្រូវបានចំណាយក្នុងការហៅ os::javaTimeMillis() ដែលត្រូវបានប្រើដើម្បីទទួលបានព័ត៌មានអំពីពេលវេលាបច្ចុប្បន្ន។ .

បន្ទាប់ពីនេះ ការពិសោធន៍មួយត្រូវបានធ្វើឡើងដែលកម្មវិធី Java សាមញ្ញមួយត្រូវបានសរសេរដែលហៅថាវិធីសាស្ត្រ System.currentTimeMillis() មួយរយលានដងក្នុងរង្វិលជុំមួយ។ ការដំណើរការកម្មវិធីបានបង្ហាញថាវាចំណាយពេល 13 វិនាទីដើម្បីបញ្ចប់នៅលើ CentOS និងប្រហែល 68 វិនាទីនៅលើ Ubuntu ពោលគឺឧ។ យឺតជាង 5 ដង។ កម្មវិធីស្រដៀងគ្នានេះត្រូវបានសរសេរនៅក្នុង C ដែលហៅថាមុខងារ gettimeofday() មួយរយលានដង ប៉ុន្តែនៅពេលប្រតិបត្តិ លទ្ធផលស្រដៀងគ្នាត្រូវបានទទួល។

ដោយសារវាច្បាស់ថាប្រភពនៃបញ្ហាគឺជាមុខងារនៃការត្រលប់មកវិញនូវពេលវេលាបច្ចុប្បន្ន ការយកចិត្តទុកដាក់បានងាកទៅរកការផ្លាស់ប្តូរសូចនាករនៅពេលជ្រើសរើសប្រភពផ្សេងៗគ្នានៃពេលវេលាពិតប្រាកដនៅក្នុងប្រព័ន្ធ។ ដោយវិនិច្ឆ័យដោយមាតិកានៃ “/sys/devices/system/clocksource/clocksource0/current_clocksource” កម្មវិធីកំណត់ម៉ោង “xen” ត្រូវបានប្រើតាមលំនាំដើមនៅពេលដំណើរការលីនុចនៅក្នុងប្រព័ន្ធភ្ញៀវ។ បន្ទាប់ពីផ្លាស់ប្តូរប្រភពពេលវេលាទៅជា "tsc" ពេលវេលាប្រតិបត្តិនៃកម្មវិធីសាកល្បងនៅក្នុងអ៊ូប៊ុនទូបានថយចុះពី 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 real 1m8.300s user 0m38.337s $ sys.0m echo tsc > /sys/devices/system/clocksource/clocksource29.875/current_clocksource $time java TimeBench real 0m0s user 3.370m0s sys 3.353m0s

ដើម្បីទទួលបានពេលវេលានៅពេលជ្រើសរើសប្រភព TSC ការណែនាំដំណើរការ RDTSC ត្រូវបានប្រើ ការប្រតិបត្តិដែលមិនតម្រូវឱ្យមានការហៅប្រព័ន្ធ (ការណែនាំមិនតម្រូវឱ្យមានសិទ្ធិកើនឡើង និងបង្កើតតម្លៃពីពេលវេលារាប់បញ្ចូលក្នុង CPU) ។ តាមលំនាំដើម TSC មិនត្រូវបានធ្វើឱ្យសកម្មទេ ពីព្រោះកាលពីសម័យដើមប្រភពនេះមិនរាប់បញ្ចូលការរំកិលពេលវេលាបន្តិចម្តងៗ ដែលនៅក្នុង processors ផ្សេងទៀតត្រូវបានកែតម្រូវដោយកម្មវិធី ដើម្បីសម្រេចបាននូវការអានត្រឹមត្រូវជាងមុន។ យោងតាមវិស្វករដែលមានឯកទេសក្នុងការអភិវឌ្ឍន៍ប្រព័ន្ធដំណើរការ ការភ័យខ្លាចអំពីការផ្លាស់ប្តូរពេលវេលានៅពេលប្រើ TSC គឺមិនពិតជាយូរមកហើយ ហើយនៅក្នុង processors ទំនើបប្រភពនេះអាចបង្កើតការអានដែលមានស្ថេរភាពអស់រយៈពេលជាច្រើនឆ្នាំ។

ការផ្លាស់ប្តូរម៉ាស៊ីនមេផលិតកម្មនៅ Netflix ទៅជាប្រភព TSC បណ្តាលឱ្យមានការថយចុះ 43% ក្នុងការសរសេរយឺត និងទទួលបានលទ្ធផលដោយប្រើអ៊ូប៊ុនទូ ដែលលឿនជាងការកំណត់រចនាសម្ព័ន្ធដំណើរការ CentOS 4 ដងជាមួយនឹងប្រភពពេលវេលា "xen" ។ លទ្ធផលនៃការសិក្សាត្រូវបានផ្ទេរទៅក្រុមហ៊ុន Amazon ដែលបានណែនាំជាផ្លូវការដោយប្រើប្រភពពេលវេលា TSC លំនាំដើមនៅក្នុងបរិស្ថាន AWS EC2 ដោយផ្អែកលើ Xen hypervisor (kvm-clock នៅតែត្រូវបានណែនាំនៅក្នុងបរិស្ថានដោយផ្អែកលើ Nitro hypervisor) ។

ប្រភព: opennet.ru