Brendan Gregg, salah sawijining pangembang DTrace, sing saiki ngembangake alat analisis kinerja berbasis BPF ing kernel Linux, ngringkes pengalaman sing dipikolehi saka nganalisa masalah kinerja sing ditemokake Netflix nalika migrasi Cassandra DBMS saka CentOS menyang Ubuntu. maya Amazon EC2 adhedhasar Xen. Sawise migrasi, beban CPU mundhak 30% lan wektu tundha sajrone operasi nulis mundhak kanthi jumlah sing padha. Ternyata, kinerja aplikasi sing njaluk informasi wektu kanthi intensif gumantung saka sumber wektu sing dipilih ing sistem kasebut.
Kaping pisanan, alesan nyuda kinerja ora jelas lan diagnosis diwiwiti kanthi ngawasi dampak sing bisa ditindakake kanthi terus-terusan utawa proses sistem intensif sumber daya sing diluncurake kanthi nggunakake utilitas ndhuwur lan execsnoop. Nanging kabeh nuduhake yen konsumsi sumber daya wis tambah khusus ing Cassandra DBMS, ditulis ing Jawa. Mbandhingake metrik profil saka rong proses Cassandra sing mlaku kanthi podo karo ing CentOS lan Ubuntu, ngolah pitakon sing padha, nuduhake yen udakara 32% saka total wektu sing digunakake kanggo nelpon os :: javaTimeMillis (), sing digunakake kanggo njupuk informasi babagan wektu saiki. .
Sawise iki, eksperimen ditindakake ing ngendi aplikasi Java prasaja ditulis sing diarani System.currentTimeMillis () cara satus yuta kaping siji. Mbukak aplikasi nuduhake yen butuh 13 detik kanggo ngrampungake ing CentOS, lan udakara 68 detik ing Ubuntu, yaiku. 5 kaping luwih alon. Program sing padha ditulis ing C sing diarani fungsi gettimeofday () satus yuta kaping, nanging nalika dieksekusi, asil sing padha dipikolehi.
Wiwit dadi cetha yen sumber masalah iku fungsi bali wektu saiki, manungsa waΓ© nguripake kanggo owah-owahan ing pratondho nalika milih macem-macem sumber wektu pas ing sistem. Ditilik saka isi "/sys/devices/system/clocksource/clocksource0/current_clocksource", timer "xen" digunakake minangka standar nalika mbukak Linux ing sistem tamu. Sawise ngganti sumber wektu dadi "tsc", wektu eksekusi aplikasi tes ing Ubuntu mudhun saka 68 dadi 3.3 detik, yaiku. dadi 20 kaping luwih cepet. Kajaba iku, tes kinerja sumber wektu kvm-jam ditindakake, sing nuduhake paningkatan tundha 20% dibandhingake karo TSC. $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ wektu java TimeBench nyata 1m8.300s pangguna 0m38.337s $ sys. echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ wektu java TimeBench nyata 29.875m0s pangguna 0m3.370s sys 0m3.353s
Kanggo entuk wektu nalika milih sumber TSC, instruksi prosesor RDTSC digunakake, eksekusi sing ora mbutuhake telpon sistem (instruksi kasebut ora mbutuhake hak istimewa sing luwih dhuwur lan ngasilake nilai saka counter wektu sing dibangun ing CPU). Kanthi gawan, TSC ora diaktifake amarga ing jaman kuna sumber iki ora ngilangi wektu drift bertahap, kang ing prosesor liyane diatur dening piranti lunak kanggo entuk maca luwih akurat. Miturut insinyur khusus ing pangembangan prosesor, rasa wedi babagan owah-owahan wektu nalika nggunakake TSC wis suwe ora bener lan ing prosesor modern, sumber iki bisa ngasilake bacaan sing stabil nganti pirang-pirang taun.
Ngalih server produksi ing Netflix menyang sumber TSC nyebabake nyuda 43% ing latensi nulis lan entuk asil nggunakake Ubuntu sing kaping 4 luwih cepet tinimbang konfigurasi sing mbukak CentOS kanthi sumber wektu "xen". Asil panaliten ditransfer menyang Amazon, sing resmi dianjurake nggunakake sumber wektu TSC standar ing lingkungan AWS EC2 adhedhasar hypervisor Xen (kvm-jam tetep dianjurake ing lingkungan adhedhasar Nitro hypervisor).
Source: opennet.ru