Brendan Gregg, salah sahiji pamekar DTrace, anu ayeuna nuju ngembangkeun parabot analisis kinerja basis BPF dina kernel Linux Ubuntu, diringkeskeun pangalaman gains tina analisa masalah kinerja anu Netflix encountered nalika migrasi Cassandra DBMS ti CentOS ka Ubuntu. awan Amazon EC2 dumasar kana Xen. Saatos migrasi, beban CPU ningkat ku 30% sareng telat salami operasi nyerat ningkat ku jumlah anu sami. Tétéla, kinerja aplikasi anu sacara intensif nyuhunkeun inpormasi waktos gumantung pisan kana sumber waktos anu dipilih dina sistem.
Mimitina, alesan pikeun panurunan dina kinerja teu écés sarta diagnosis dimimitian ku mantau dampak mungkin tina terus ngajalankeun atawa périodik dibuka prosés sistem sumberdaya-intensif ngagunakeun Utiliti luhur jeung execsnoop. Tapi sagalana nunjukkeun yén konsumsi sumberdaya geus ngaronjat husus dina Cassandra DBMS, ditulis dina Java. Ngabandingkeun métrik profil tina dua prosés Cassandra jalan paralel on CentOS na Ubuntu, ngolah queries sarua, némbongkeun yén ngeunaan 32% tina total waktu ieu spent nelepon os :: javaTimeMillis (), nu dipaké pikeun ménta inpo ngeunaan waktos ayeuna. .
Saatos ieu, percobaan dilakukeun dimana aplikasi Java basajan ditulis anu disebut metode System.currentTimeMillis () saratus juta kali dina loop. Ngajalankeun aplikasi nunjukkeun yén butuh 13 detik kanggo réngsé dina CentOS, sareng sakitar 68 detik dina Ubuntu, nyaéta. 5 kali leuwih laun. Hiji program sarupa ieu ditulis dina C nu disebut gettimeofday () fungsi saratus juta kali, tapi lamun dieksekusi, hasilna sarupa diala.
Kusabab éta jelas yén sumber masalah éta fungsi mulangkeun waktos ayeuna, perhatian ngancik kana parobahan dina indikator lamun milih sumber béda waktu pasti dina sistem. Ditilik ku eusi "/sys/devices/system/clocksource/clocksource0/current_clocksource", timer "xen" dianggo sacara standar nalika ngajalankeun Linux dina sistem tamu. Saatos ngarobih sumber waktos janten "tsc", waktos palaksanaan aplikasi uji di Ubuntu turun tina 68 dugi ka 3.3 detik, nyaéta. eta janten 20 kali leuwih gancang. Salaku tambahan, uji kinerja sumber waktos kvm-jam dilaksanakeun, anu nunjukkeun paningkatan telat ku 20% dibandingkeun sareng TSC. $ ucing /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ ucing /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ time java TimeBench nyata 1m8.300s pamaké 0m38.337s $ sy. gema tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ time java TimeBench nyata 29.875m0s pamaké 0m3.370s sys 0m3.353s
Pikeun ménta waktu nalika milih sumber TSC dipaké instruksi processor RDTSC, palaksanaan nu teu merlukeun panggero sistem (instruksi teu merlukeun hak husus elevated sarta ngahasilkeun nilai ti counter waktos diwangun kana CPU). Sacara standar, TSC henteu diaktipkeun sabab dina jaman baheula sumber ieu henteu ngaluarkeun waktos drift bertahap, anu dina prosesor sanésna disaluyukeun ku parangkat lunak pikeun ngahontal bacaan anu langkung akurat. Numutkeun saurang insinyur anu khusus dina pamekaran prosésor, kasieunan ngeunaan pergeseran waktos nalika nganggo TSC parantos lami teu leres sareng dina prosesor modéren sumber ieu tiasa ngahasilkeun bacaan anu stabil salami mangtaun-taun.
Ngalihkeun server produksi di Netflix ka sumber TSC nyababkeun pangurangan 43% dina latensi nyerat sareng ngahontal hasil nganggo Ubuntu anu 4 kali langkung gancang tibatan konfigurasi anu ngajalankeun CentOS kalayan sumber waktos "xen". Hasil ulikan ditransferkeun ka Amazon, anu sacara resmi nyarankeun ngagunakeun sumber waktos TSC standar dina lingkungan AWS EC2 dumasar kana hypervisor Xen (kvm-jam tetep disarankeun dina lingkungan dumasar kana Nitro hypervisor).
sumber: opennet.ru