Süsteemis valitud ajaallika tulemuslikkuse mõju analüüs

Brendan Gregg, üks DTrace'i arendajatest, kes arendab praegu Linuxi tuumas BPF-põhiseid jõudlusanalüüsi tööriistu, võttis kokku kogemused, mis on saadud nende jõudlusprobleemide analüüsimisel, millega Netflix tekkis Cassandra DBMS-i migreerimisel CentOS-ist Ubuntu. Xenil põhinev Amazon EC2 pilv. Pärast migratsiooni suurenes protsessori koormus 30% ja kirjutamistoimingute viivitused suurenesid umbes sama palju. Nagu selgub, sõltub intensiivselt ajainfot küsivate rakenduste jõudlus väga palju süsteemi valitud täpsest ajaallikast.

Esialgu ei olnud jõudluse languse põhjus ilmne ja diagnoos algas pidevalt töötavate või perioodiliselt käivitatavate ressursimahukate süsteemiprotsesside võimaliku mõju jälgimisest top ja execsnoop utiliitide abil. Kuid kõik viitas sellele, et ressursside tarbimine oli suurenenud just Java keeles kirjutatud Cassandra DBMS-is. Kahe CentOS-is ja Ubuntus paralleelselt töötava, samu päringuid töötleva Cassandra protsessi profileerimismõõdikute võrdlemine näitas, et umbes 32% kogu ajast kulus os::javaTimeMillis() helistamisele, mida kasutatakse praeguse aja kohta teabe hankimiseks. .

Pärast seda viidi läbi eksperiment, mille käigus kirjutati lihtne Java rakendus, mis kutsus System.currentTimeMillis() meetodit sada miljonit korda tsüklina. Rakenduse käivitamine näitas, et CentOS-is kulus valmimiseks 13 sekundit, Ubuntul aga umbes 68 sekundit, s.o. 5 korda aeglasem. C-s kirjutati sarnane programm, mis kutsus funktsiooni gettimeofday() sada miljonit korda, kuid käivitamisel saadi sarnased tulemused.

Kuna selgus, et probleemi allikaks on jooksva kellaaja tagastamise funktsioon, pöörati süsteemis erinevate täpse aja allikate valimisel tähelepanu näitajate muutustele. Otsustades jaotise „/sys/devices/system/clocksource/clocksource0/current_clocksource” sisu järgi, kasutati külalissüsteemis Linuxi käitamisel vaikimisi taimerit „xen”. Pärast ajaallika muutmist "tsc-ks" vähenes Ubuntu testrakenduse täitmisaeg 68-lt 3.3 sekundile, s.o. see muutus 20 korda kiiremaks. Lisaks viidi läbi kvm-kella ajaallika jõudluse test, mis näitas viivituste suurenemist 20% võrreldes TSC-ga. $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ aeg java TimeBench päris 1m8.300s kasutaja 0m38.337s0 sys.29.875. echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ aeg java TimeBench reaalne 0m3.370s kasutaja 0m3.353s sys 0m0.026s

Aja saamiseks TSC allika valimisel kasutatakse RDTSC protsessori käsku, mille täitmine ei nõua süsteemikutset (käsk ei nõua kõrgendatud õigusi ja annab väärtuse CPU-sse sisseehitatud ajaloendurilt). Vaikimisi ei ole TSC aktiveeritud, sest vanasti ei välistanud see allikas järkjärgulist aja triivi, mida teistes protsessorites reguleerib tarkvara, et saavutada täpsemaid näitu. Protsessorite arendamisele spetsialiseerunud inseneri sõnul on hirmud ajaliste nihkete pärast TSC kasutamisel juba ammu paika pandud ja tänapäevastes protsessorites võib see allikas anda stabiilseid näitu aastaid.

Netflixi tootmisserverite vahetamine TSC-allika vastu vähendas kirjutamislatentsust 43% ja saavutas Ubuntu abil tulemusi, mis olid 4 korda kiiremad kui konfiguratsioonid, mis käitasid CentOS-i koos „xen” ajaallikaga. Uuringu tulemused kanti üle Amazonile, kes soovitas ametlikult kasutada vaikimisi TSC ajaallikat AWS EC2 keskkondades, mis põhinevad Xen hüperviisoril (kvm-kell jääb soovitavaks Nitro hüperviisoril põhinevates keskkondades).

Allikas: opennet.ru

Lisa kommentaar