Brendan Gregg, üks DTrace'i arendajatest, kes praegu arendab BPF-põhiseid jõudluse analüüsi tööriistu Linuxi kernelis, on kokkuvõtlikult jaganud kogemusi, mis saadud jõudlusprobleemide lahendamisel, millega Netflix silmitsi seisis, kui nad migreerisid andmebaasi Cassandra CentOS-ist Ubuntu-sse Amazon EC2 Xen-i keskkondades. Pärast migratsiooni suurenes CPU koormus 30% ja umbes sama palju kasvasid ka kirjutamisoperatsioonide latentsus. Selgus, et rakenduste jõudlus, mis kasutavad intensiivselt aega nõudvaid päringuid, sõltub väga palju valitud süsteemi täpsest ajalooallikast.
Alguses ei olnud jõudluse vähenemise põhjus selge ning diagnostika algas süsteemiprotsesside jälgimisest, mis töötavad pidevalt või käivitatakse perioodiliselt, kasutades utiliite top ja execsnoop. Kuid kõik viitas sellele, et ressursi tarbimine suurenes just Java keeles kirjutatud Cassandra andmebaasis. Kahe Cassandra protsessi, mis töötasid paralleelselt CentOS-is ja Ubuntu-s ning töötlesid samu päringuid, profiilide võrdlemine näitas, et umbes 32% kogu ajast kulub os::javaTimeMillis() üleskutse tegemiseks, mida kasutatakse praeguse aja teabe saamiseks.
Pärast seda viidi läbi eksperiment, milles kirjutati lihtne Java rakendus, mis kutsus tsüklis üles sajat miljonit korda meetodit System.currentTimeMillis(). Rakenduse käivitamine näitas, et CentOS-is kulus selle täitmiseks 13 sekundit, kuid Ubuntu-s umbes 68 sekundit, s.t. 5 korda aeglasem. Sarnane programm kirjutati C keeles, mis kutsus sajat miljonit korda üles gettimeofday() funktsiooni, kuid selle täitmisel saadi sarnased tulemused.
Kuna on selge, et probleemi allikaks on praeguse aja tagastamise funktsioon, pöörati tähelepanu mõõdikute muutmisele süsteemis, kui valitakse erinevad täpsuse ajad. Lähtuvalt failisisust "/sys/devices/system/clocksource/clocksource0/current_clocksource" kasutati vaikimisi Linuxi käivitamisel külgikonnas ajastit "xen". Ajaallika muutmisega "tsc" aastatest testirakenduse töötamise aeg Ubuntus vähenes 68-lt 3,3 sekundile, s.o. see kiirenes 20 korda. Täiendavalt viidi läbi kvm-clock tarnija jõudlustesti, mis näitas 20% viivituste suurenemist võrreldes TSC-iga.$ 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 0m38.337s sys 0m29.875s$ echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource$ time java TimeBench real 0m3.370s user 0m3.353s sys 0m0.026s
TSC allika valimisel kasutatakse aega saamiseks protsessori instruktsiooni RDTSC, mille täitmine ei nõua süsteemikõne tegemist (instruktsioon ei vaja kõrgendatud õigusi ja annab väärtuse CPU-sse sisseehitatud ajaklassi loendurist). Vaikimisi ei aktiveerita TSC, kuna minevikus ei välistanud see allikas aja järkjärgulist triivimist, mida muudes töötlejates korrigeeritakse tarkvara abil täpsemate näitude saavutamiseks. Inseneri arvates, kes on spetsialiseerunud protsessorite arendamisele, ei vasta mured TSC kasutamisel aja nihke kohta enam ammu tegelikkusele ja kaasaegsetes protsessorites võib see allikas aastaid anda stabiilseid näitusid.
Tööde tõlke serverite Netflixis TSC allikas vähendas salvestamise latentsust 43% ja saavutas Ubuntu kasutamisel tulemusi, mis ületasid CentOS konfiguratsioonide tulemusi neljakordselt ajavõtme 'xen' kasutamisel. Uuringu tulemused edastati ettevõttele Amazon, mis soovitas ametlikult AWS EC2 Xen hüperviisorite keskkondades vaikimisi kasutada TSC ajallikat (Nitro hüperviisorite keskkondades jääb soovitatavaks kvm-clock).
Allikas: opennet.ru
