Brendan Gregg, yksi DTracen kehittäjistä, joka kehittää parhaillaan BPF-pohjaisia suorituskykyanalyysityökaluja Linux-ytimeen, tiivisti kokemuksesta, joka on saatu analysoimalla suorituskykyongelmia, joita Netflix kohtasi siirrettäessä Cassandra DBMS:ää CentOS:stä Ubuntu.-ympäristöihin. Xeniin perustuva Amazon EC2 -pilvi. Siirron jälkeen suorittimen kuormitus kasvoi 30 % ja kirjoitustoimintojen viiveet kasvoivat suunnilleen saman verran. Kuten on käynyt ilmi, intensiivisesti aikatietoja pyytävien sovellusten suorituskyky riippuu suuresti järjestelmään valitusta tarkasta aikalähteestä.
Aluksi syy suorituskyvyn heikkenemiseen ei ollut ilmeinen ja diagnoosi aloitettiin seuraamalla jatkuvasti käynnissä olevien tai ajoittain käynnissä olevien resurssiintensiivisten järjestelmäprosessien mahdollisia vaikutuksia top- ja execsnoop-apuohjelmilla. Mutta kaikki osoitti, että resurssien kulutus oli lisääntynyt erityisesti Java-kielellä kirjoitetussa Cassandra DBMS:ssä. Kahden CentOS:ssä ja Ubuntussa rinnakkain käynnissä olevan, samoja kyselyjä käsittelevän Cassandra-prosessin profilointimittareiden vertailu osoitti, että noin 32 % kokonaisajasta kului os::javaTimeMillis(), jota käytetään tiedon saamiseksi nykyisestä ajasta. .
Tämän jälkeen tehtiin koe, jossa kirjoitettiin yksinkertainen Java-sovellus, joka kutsui System.currentTimeMillis()-menetelmää sata miljoonaa kertaa silmukassa. Sovelluksen suorittaminen osoitti, että sen valmistuminen kesti CentOS:lla 13 sekuntia ja Ubuntussa noin 68 sekuntia, ts. 5 kertaa hitaampi. C:ssä kirjoitettiin samanlainen ohjelma, joka kutsui gettimeofday()-funktiota sata miljoonaa kertaa, mutta suoritettuna saatiin samanlaisia tuloksia.
Kun kävi selväksi, että ongelman lähde oli nykyisen ajan palautustoiminto, huomio kiinnitettiin indikaattoreiden muutoksiin valittaessa järjestelmään erilaisia tarkan ajan lähteitä. Päätellen "/sys/devices/system/clocksource/clocksource0/current_clocksource" sisällöstä, "xen"-ajastinta käytettiin oletuksena käytettäessä Linuxia vierasjärjestelmässä. Kun aikalähde oli vaihdettu "tsc:ksi", testisovelluksen suoritusaika Ubuntussa lyheni 68:sta 3.3 sekuntiin, ts. siitä tuli 20 kertaa nopeampi. Lisäksi suoritettiin kvm-kellon aikalähteen suorituskykytesti, joka osoitti viiveiden lisääntymistä 20 % verrattuna TSC:hen. $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ aika java TimeBench todellinen 1m8.300s käyttäjä 0m38.337s0 sys29.875. echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ aika java TimeBench real 0m3.370s user 0m3.353s sys 0m0.026s
Ajan saamiseksi TSC-lähdettä valittaessa käytetään RDTSC-prosessorikäskyä, jonka suorittaminen ei vaadi järjestelmäkutsua (käsky ei vaadi korotettuja oikeuksia ja tuottaa arvon CPU:hun sisäänrakennetusta aikalaskurista). Oletuksena TSC ei ole aktivoitu, koska vanhaan aikaan tämä lähde ei sulkenut pois asteittaista aikaryömintä, jota muissa prosessoreissa säädetään ohjelmistolla tarkempien lukemien saavuttamiseksi. Prosessorikehitykseen erikoistuneen insinöörin mukaan pelot aikasiirtymistä TSC:tä käytettäessä ovat olleet pitkään perättömiä ja nykyaikaisissa prosessoreissa tämä lähde voi tuottaa vakaita lukemia vuosia.
Netflixin tuotantopalvelimien vaihtaminen TSC-lähteeseen johti 43 %:n laskuun kirjoitusviiveeseen ja saavutti tuloksia käyttämällä Ubuntua, jotka olivat 4 kertaa nopeampia kuin kokoonpanoissa, joissa CentOS käytettiin "xen"-aikalähteellä. Tutkimuksen tulokset siirrettiin Amazonille, joka virallisesti suositteli oletusarvoisen TSC-aikalähteen käyttöä Xen-hypervisoriin perustuvissa AWS EC2 -ympäristöissä (kvm-kello pysyy suositeltuna Nitro-hypervisoriin perustuvissa ympäristöissä).
Lähde: opennet.ru