Brendan Gregg, ɗaya daga cikin masu haɓaka DTrace, wanda a halin yanzu yana haɓaka kayan aikin bincike na tushen BPF a cikin Linux kernel, ya taƙaita ƙwarewar da aka samu daga nazarin matsalolin aikin da Netflix ya fuskanta lokacin ƙaura Cassandra DBMS daga CentOS zuwa Ubuntu. Amazon EC2 girgije bisa Xen. Bayan ƙaura, nauyin CPU ya ƙaru da kashi 30% kuma jinkiri yayin ayyukan rubutu ya ƙaru da kusan adadin. Kamar yadda ya fito, aikin aikace-aikacen da ke buƙatar bayanan lokaci sosai ya dogara da ainihin tushen lokacin da aka zaɓa a cikin tsarin.
Da farko, dalilin raguwar aikin ba a bayyane yake ba kuma ganewar asali ya fara ne tare da lura da tasirin tasirin da ake yi na ci gaba da gudana ko kuma kaddamar da tsarin tsarin lokaci-lokaci ta hanyar amfani da kayan aiki na sama da na execsnoop. Amma komai ya nuna cewa amfani da albarkatun ya ƙaru musamman a cikin Cassandra DBMS, wanda aka rubuta a cikin Java. Kwatanta ma'auni na bayanan tsarin Cassandra guda biyu da ke gudana a layi daya akan CentOS da Ubuntu, sarrafa tambayoyin iri ɗaya, ya nuna cewa kusan kashi 32% na jimlar lokacin da aka kashe ana kiran os :: javaTimeMillis (), wanda ake amfani da shi don samun bayanai game da lokacin da ake ciki yanzu. .
Bayan haka, an gudanar da gwaji inda aka rubuta aikace-aikacen Java mai sauƙi wanda ake kira tsarin System.currentTimeMillis() sau miliyan ɗari a madauki. Gudanar da aikace-aikacen ya nuna cewa ya ɗauki daƙiƙa 13 don kammalawa akan CentOS, kuma kusan daƙiƙa 68 akan Ubuntu, watau. Sau 5 a hankali. An rubuta irin wannan shirin a cikin C wanda ake kira aikin gettimeofday () sau miliyan dari, amma lokacin da aka aiwatar da shi, an sami irin wannan sakamako.
Tun da ya bayyana a fili cewa tushen matsalar shine aikin dawo da lokaci na yanzu, hankali ya juya ga canje-canje a cikin alamun lokacin zabar maɓuɓɓuka daban-daban na ainihin lokaci a cikin tsarin. Yin la'akari da abubuwan da ke cikin "/ sys / na'urori / tsarin / clocksource / clocksource0/current_clocksource", an yi amfani da ma'aunin lokaci na "xen" ta tsohuwa lokacin gudanar da Linux a cikin tsarin baƙi. Bayan canza tushen lokaci zuwa "tsc", lokacin aiwatar da aikace-aikacen gwaji a Ubuntu ya ragu daga 68 zuwa 3.3 seconds, watau. ya zama sauri sau 20. Bugu da ƙari, an gudanar da gwajin aiki na tushen lokacin agogon kvm, wanda ya nuna karuwar jinkiri da kashi 20% idan aka kwatanta da TSC. $ cat /sys/na'urori/system/ clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/na'urorin/system/clocksource/clocksource0/current_clocksource xen $ lokaci java TimeBench real 1m8.300s mai amfani 0m38.337s $sys 0m29.875s sys. echo tsc > / sys / na'urori / tsarin / tushen agogo / clocksource0 / tushen_clocksource $ lokaci java TimeBench ainihin 0m3.370s mai amfani 0m3.353s sys 0m0.026s
Don samun lokacin zabar tushen TSC, ana amfani da umarnin sarrafawa na RDTSC, wanda aiwatar da shi baya buƙatar kiran tsarin (umarnin ba ya buƙatar manyan gata kuma yana samar da ƙima daga ma'aunin lokaci da aka gina a cikin CPU). Ta hanyar tsoho, ba a kunna TSC ba saboda a zamanin da wannan tushen bai keɓance saurin lokaci ba a hankali, wanda a cikin sauran na'urori ana daidaita su ta hanyar software don samun ingantaccen karatu. A cewar wani injiniya da ya ƙware a haɓaka kayan masarufi, tsoro game da sauye-sauyen lokaci yayin amfani da TSC ya daɗe ba gaskiya ba ne kuma a cikin na'urori na zamani wannan tushen yana iya samar da ingantaccen karatu tsawon shekaru.
Canjawar sabobin samarwa a Netflix zuwa tushen TSC ya haifar da raguwar 43% a cikin latency rubutu kuma an sami sakamako ta amfani da Ubuntu wanda ya kasance sau 4 cikin sauri fiye da jeri da ke gudana CentOS tare da tushen lokacin "xen". Sakamakon binciken an canza shi zuwa Amazon, wanda bisa hukuma ya ba da shawarar yin amfani da tsohuwar tushen lokacin TSC a cikin mahallin AWS EC2 dangane da hypervisor Xen (kvm-agogo ya kasance da shawarar a cikin mahalli dangane da Nitro hypervisor).
source: budenet.ru