Brendanas Greggas, vienas iš DTrace kūrėjų, šiuo metu kuriantis BPF pagrindu veikiančius našumo analizės įrankius Linux branduolyje, apibendrino patirtį, įgytą analizuojant našumo problemas, su kuriomis susidūrė Netflix perkeldama Cassandra DBVS iš CentOS į Ubuntu aplinkas, kuriose veikia „Amazon EC2“ debesis, pagrįstas Xen. Po perkėlimo procesoriaus apkrova padidėjo 30%, o rašymo operacijų vėlavimai padidėjo maždaug tiek pat. Pasirodo, intensyviai laiko informacijos prašančių programų veikimas labai priklauso nuo sistemoje pasirinkto tikslaus laiko šaltinio.
Iš pradžių našumo sumažėjimo priežastis nebuvo akivaizdi, o diagnozė prasidėjo stebint galimą nuolat veikiančių ar periodiškai paleidžiamų daug išteklių reikalaujančių sistemos procesų poveikį, naudojant aukščiausios ir execsnoop programas. Tačiau viskas rodė, kad išteklių suvartojimas ypač padidėjo Cassandra DBVS, parašytoje Java kalba. Palyginus dviejų lygiagrečiai CentOS ir Ubuntu veikiančių Cassandra procesų profiliavimo metrikas, apdorojant tas pačias užklausas, paaiškėjo, kad apie 32 % viso laiko buvo praleista skambinant os::javaTimeMillis(), kuri naudojama informacijai apie esamą laiką gauti. .
Po to buvo atliktas eksperimentas, kurio metu buvo parašyta paprasta „Java“ programa, kuri šimtą milijonų kartų grandinėje iškvietė System.currentTimeMillis() metodą. Paleidus aplikaciją paaiškėjo, kad CentOS ją užbaigti prireikė 13 sekundžių, o Ubuntu – apie 68 sekundes, t.y. 5 kartus lėčiau. Panaši programa buvo parašyta C kalboje, kuri šimtą milijonų kartų iškvietė funkciją gettimeofday(), tačiau ją vykdant buvo gauti panašūs rezultatai.
Paaiškėjus, kad problemos šaltinis yra esamo laiko grąžinimo funkcija, renkantis skirtingus tikslaus laiko šaltinius sistemoje dėmesys nukrypo į rodiklių pokyčius. Sprendžiant iš „/sys/devices/system/clocksource/clocksource0/current_clocksource“ turinio, „xen“ laikmatis buvo naudojamas pagal numatytuosius nustatymus, kai „Linux“ veikia svečių sistemoje. Pakeitus laiko šaltinį į „tsc“, Ubuntu bandomosios aplikacijos vykdymo laikas sumažėjo nuo 68 iki 3.3 sekundės, t.y. jis tapo 20 kartų greitesnis. Be to, buvo atliktas kvm-laikrodžio laiko šaltinio veikimo testas, kuris parodė, kad vėlavimai padidėjo 20%, palyginti su TSC. $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ laikas java TimeBench real 1m8.300s user 0m38.337s0 sys.29.875. echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ laikas java TimeBench real 0m3.370s user 0m3.353s sys 0m0.026s
Laikui gauti renkantis TSC šaltinį naudojama RDTSC procesoriaus instrukcija, kurios vykdymui nereikia sistemos iškvietimo (instrukcija nereikalauja padidintų privilegijų ir sukuria reikšmę iš CPU įtaisyto laiko skaitiklio). Pagal numatytuosius nustatymus TSC nėra aktyvuotas, nes senais laikais šis šaltinis neatmetė laipsniško laiko dreifo, kuris kituose procesoriuose yra koreguojamas programine įranga, kad būtų pasiekti tikslesni rodmenys. Pasak inžinieriaus, besispecializuojančio procesorių kūrimo srityje, nuogąstavimai dėl laiko poslinkių naudojant TSC jau seniai buvo neteisingi, o šiuolaikiniuose procesoriuose šis šaltinis gali pateikti stabilius rodmenis daugelį metų.
Perjungus gamybinius „Netflix“ serverius į TSC šaltinį, rašymo delsa sumažėjo 43%, o naudojant „Ubuntu“ buvo pasiekti rezultatai, kurie buvo 4 kartus greitesni nei konfigūracijos, kuriose veikia „CentOS“ su „xen“ laiko šaltiniu. Tyrimo rezultatai buvo perkelti į „Amazon“, kuri oficialiai rekomendavo naudoti numatytąjį TSC laiko šaltinį AWS EC2 aplinkose, pagrįstose Xen hipervizoriumi (kvm laikrodis išlieka rekomenduojamas aplinkose, pagrįstose Nitro hipervizoriumi).
Šaltinis: opennet.ru