UBrendan Gregg, omnye wabaphuhlisi be-DTrace, okwangoku ephuhlisa izixhobo zokuhlalutya ukusebenza okusekwe kwi-BPF kwi-Linux kernel, ushwankathele amava afunyenwe ekuhlalutyeni iingxaki zentsebenzo ezafunyanwa yiNetflix xa ifuduka iCassandra DBMS isuka kwiCentOS isiya Ubuntu. i-Amazon EC2 ilifu esekwe kwi-Xen. Emva kokufuduka, umthwalo we-CPU unyuke nge-30% kwaye ukulibaziseka ngexesha lokubhala imisebenzi kwanda malunga nesixa esifanayo. Njengoko kuvela, ukusebenza kwezicelo ezicela ngokunzulu ulwazi lwexesha kakhulu kuxhomekeke kumthombo wexesha elichanekileyo elikhethiweyo kwisistim.
Ekuqaleni, isizathu sokuhla komgangatho wokusebenza sasingabonakali kwaye ukuxilongwa kwaqala ngokubeka esweni impembelelo enokubakho yokusebenza rhoqo okanye ukuqaliswa kwamaxesha athile kweenkqubo zenkqubo yezibonelelo kusetyenziswa izixhobo eziphezulu kunye ne-execsnoop. Kodwa yonke into ibonise ukuba ukusetyenziswa kwezixhobo kuye kwanda ngokukodwa kwiCassandra DBMS, ebhalwe kwiJava. Ukuthelekisa i-profiling metrics yeenkqubo ezimbini zeCassandra ezisebenza ngokufanayo kwi-CentOS kunye no-Ubuntu, ukusetyenzwa kwemibuzo efanayo, kubonise ukuba malunga ne-32% yexesha elipheleleyo elichithwe ukufowunela i-os::javaTimeMillis (), esetyenziselwa ukufumana ulwazi malunga nexesha langoku. .
Emva koku, uvavanyo lwenziwe apho isicelo esilula seJava sabhalwa ebizwa ngokuba yi-System.currentTimeMillis () indlela yekhulu lezigidi amaxesha kwilophu. Ukuqhuba isicelo kubonise ukuba kuthathe imizuzwana ye-13 ukugqiba kwi-CentOS, kwaye malunga nemizuzwana ye-68 ku-Ubuntu, i.e. 5 amaxesha kancinci. Inkqubo efanayo yabhalwa ngo C eyabiza gettimeofday() umsebenzi izihlandlo ezilikhulu lezigidi, kodwa xa isenziwa, iziphumo ezifanayo zafunyanwa.
Ekubeni kwacaca ukuba umthombo wengxaki ngumsebenzi wokubuyisela ixesha langoku, ingqalelo yajika kwiinguqu kwiimpawu xa ukhetha imithombo eyahlukeneyo yexesha elichanekileyo kwinkqubo. Ngokujonga imixholo ye "/sys/devices/system/clocksource/clocksource0/current_clocksource," "xen" isibali sisetyenziswe ngokungagqibekanga xa kusetyenziswa iLinux kwinkqubo yeendwendwe. Emva kokutshintsha umthombo wexesha kwi "tsc", ixesha lokwenziwa kwesicelo sovavanyo kwi-Ubuntu lehla ukusuka kwi-68 ukuya kwi-3.3 imizuzwana, okt. yaba ngamaxesha angama-20 ngokukhawuleza. Ukongezelela, uvavanyo lwentsebenzo yomthombo wexesha le-kvm-clock lwenziwa, olubonise ukunyuka kokulibaziseka ngama-20% xa kuthelekiswa ne-TSC. $ ikati /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ ixesha java TimeBench real 1m8.300s umsebenzisi 0m38.337s 0s 29.875 $s sy. echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ ixesha java TimeBench real 0m3.370s umsebenzisi 0m3.353s sys 0m0.026s
Ukufumana ixesha xa ukhetha umthombo we-TSC, umyalelo weprosesa we-RDTSC usetyenziswa, ukuphunyezwa okungafuneki umnxeba wenkqubo (umyalelo awufuni amalungelo aphakamileyo kwaye uvelise ixabiso elivela kwi-counter counter eyakhelwe kwi-CPU). Ngokungagqibekanga, i-TSC ayenziwanga isebenze kuba ngeentsuku zakudala lo mthombo awuzange ukhuphe i-drift yexesha elithe chu, ethi kwezinye iiprosesa zihlengahlengiswe yisoftware ukuze kufundwe ngokuchanekileyo. Ngokutsho kwenjineli ejongene nophuhliso lweprosesa, uloyiko malunga nokutshintsha kwexesha xa usebenzisa i-TSC ixesha elide aliyonyani kwaye kwiiprosesa zanamhlanje lo mthombo unokuvelisa ukufundwa okuzinzileyo iminyaka.
Ukutshintsha iiseva zokuvelisa kwi-Netflix kumthombo we-TSC kubangele ukunciphisa i-43% kwi-latency yokubhala kunye neziphumo eziphunyeziweyo usebenzisa i-Ubuntu ephindwe kabini ngokukhawuleza kunokwakheka kwe-CentOS kunye nomthombo wexesha "xen". Iziphumo zophononongo zidluliselwe kwiAmazon, ecetyiswe ngokusemthethweni ukuba kusetyenziswe ixesha elingagqibekanga le-TSC kwimo ye-AWS EC4 esekwe kwi-Xen hypervisor (i-kvm-clock ihlala inconywa kwiindawo ezisekelwe kwi-Nitro hypervisor).
umthombo: opennet.ru