Брендан Грег, еден од развивачите на DTrace, кој моментално развива алатки за анализа на перформанси базирани на BPF во кернелот на Linux, го сумираше искуството стекнато од анализата на проблемите со перформансите со кои се соочи Netflix при мигрирање на Cassandra DBMS од CentOS во Ubuntu. облакот Amazon EC2 базиран на Xen. По миграцијата, оптоварувањето на процесорот се зголеми за 30%, а доцнењата за време на операциите за запишување се зголемија за приближно иста количина. Како што се испоставува, перформансите на апликациите кои интензивно бараат информации за времето многу зависи од точниот временски извор избран во системот.
Отпрвин, причината за намалувањето на перформансите не беше очигледна и дијагнозата започна со следење на можното влијание на постојано извршување или периодично стартувани системски процеси со интензивни ресурси со користење на врвните и execsnoop комуналните услуги. Но, сè покажа дека потрошувачката на ресурси е зголемена конкретно во Касандра DBMS, напишана на Java. Споредувањето на метриката за профилирање на два процеси на Касандра кои работат паралелно на CentOS и Ubuntu, обработувајќи ги истите прашања, покажа дека околу 32% од вкупното време е потрошено за повикување на os::javaTimeMillis(), што се користи за добивање информации за тековното време .
После ова, беше спроведен експеримент во кој беше напишана едноставна Java апликација која го нарекува методот System.currentTimeMillis() сто милиони пати во јамка. Вклучувањето на апликацијата покажа дека се потребни 13 секунди за да се заврши на CentOS, а околу 68 секунди на Ubuntu, т.е. 5 пати побавно. Слична програма беше напишана во C која ја повика функцијата gettimeofday() сто милиони пати, но кога беше извршена, беа добиени слични резултати.
Бидејќи стана јасно дека изворот на проблемот е функцијата за враќање на тековното време, вниманието се сврте кон промените во индикаторите при изборот на различни извори на точното време во системот. Судејќи според содржината на „/sys/devices/system/clocksource/clocksource0/current_clocksource“, тајмерот „xen“ стандардно се користел кога работи Linux во системот за гости. По промената на изворот на времето во „tsc“, времето на извршување на тест апликацијата во Ubuntu се намали од 68 на 3.3 секунди, т.е. стана 20 пати побрзо. Дополнително, беше извршен тест за изведба на изворот на време kvm-clock, кој покажа зголемување на доцнењата за 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 0s echo tsc > /sys/devices/system/clocksource/clocksource38.337/current_clocksource $ time java TimeBench вистински 0m29.875s корисник 0m0s sys 3.370m0s
За да се добие време при избор на извор на TSC, се користи инструкцијата за процесорот RDTSC, за чие извршување не е потребен системски повик (инструкцијата не бара зголемени привилегии и произведува вредност од бројачот на време вграден во процесорот). Стандардно, TSC не е активиран бидејќи во старите денови овој извор не го исклучуваше постепеното временско движење, кое кај другите процесори се прилагодува со софтвер за да се постигнат попрецизни отчитувања. Според инженер специјализиран за развој на процесори, стравувањата за временските поместувања при користење на TSC одамна се невистинити и кај современите процесори овој извор може да произведува стабилни отчитувања со години.
Префрлањето на производствените сервери во Netflix на извор на TSC резултираше со 43% намалување на латентноста на пишувањето и постигнати резултати со користење на Ubuntu кои беа 4 пати побрзи од конфигурациите што работат на CentOS со извор на време „xen“. Резултатите од студијата беа пренесени на Амазон, кој официјално препорача користење на стандардниот извор на време TSC во средини AWS EC2 базирани на хипервизорот Xen (kvm-часовникот останува препорачан во средини базирани на хипервизорот Nitro).
Извор: opennet.ru