Brendan Gregg, en av utviklerne av DTrace, som for tiden utvikler BPF-baserte ytelsesanalyseverktøy i Linux-kjernen, oppsummerte erfaringene fra å analysere ytelsesproblemene som Netflix møtte ved migrering av Cassandra DBMS fra CentOS til Ubuntu.-miljøer som kjører på Amazon EC2-skyen basert på Xen. Etter migrering økte CPU-belastningen med 30 % og forsinkelsene under skriveoperasjoner økte med omtrent samme mengde. Som det viser seg, avhenger ytelsen til applikasjoner som intensivt ber om tidsinformasjon veldig av den nøyaktige tidskilden som er valgt i systemet.
Til å begynne med var årsaken til nedgangen i ytelse ikke åpenbar, og diagnosen begynte med å overvåke den mulige effekten av konstant kjørende eller periodisk lanserte ressurskrevende systemprosesser ved å bruke topp- og execsnoop-verktøyene. Men alt tydet på at ressursforbruket hadde økt spesifikt i Cassandra DBMS, skrevet i Java. Sammenligning av profileringsberegningene til to Cassandra-prosesser som kjører parallelt på CentOS og Ubuntu, behandlet de samme spørringene, viste at omtrent 32 % av den totale tiden ble brukt på å ringe os::javaTimeMillis(), som brukes til å få informasjon om gjeldende tidspunkt .
Etter dette ble det utført et eksperiment der det ble skrevet en enkel Java-applikasjon som kalte System.currentTimeMillis()-metoden hundre millioner ganger i en sløyfe. Å kjøre applikasjonen viste at det tok 13 sekunder å fullføre på CentOS, og omtrent 68 sekunder på Ubuntu, dvs. 5 ganger langsommere. Et lignende program ble skrevet i C som kalte funksjonen gettimeofday() hundre millioner ganger, men når det ble utført, ble lignende resultater oppnådd.
Siden det ble klart at kilden til problemet var funksjonen av å returnere gjeldende tid, ble oppmerksomheten rettet mot endringer i indikatorer ved valg av forskjellige kilder til nøyaktig tid i systemet. Etter innholdet i "/sys/devices/system/clocksource/clocksource0/current_clocksource" ble "xen"-timeren brukt som standard når du kjører Linux i gjestesystemet. Etter å ha endret tidskilden til "tsc", sank utførelsestiden for testapplikasjonen i Ubuntu fra 68 til 3.3 sekunder, dvs. det ble 20 ganger raskere. I tillegg ble det utført en ytelsestest av kvm-klokke-tidskilden, som viste en økning i forsinkelser med 20 % sammenlignet med TSC. $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ tid java TimeBench real 1m8.300s bruker 0m38.337s $0m echo tsc > /sys/devices/system/clocksource/clocksource29.875/current_clocksource $ tid java TimeBench real 0m0s bruker 3.370m0s sys 3.353m0s
For å få tiden når du velger en TSC-kilde, brukes RDTSC-prosessorinstruksjonen, hvis utførelse ikke krever et systemanrop (instruksjonen krever ikke forhøyede privilegier og produserer en verdi fra tidstelleren innebygd i CPU). Som standard er ikke TSC aktivert fordi denne kilden i gamle dager ikke utelukket gradvis tidsdrift, som i andre prosessorer justeres av programvare for å oppnå mer nøyaktige avlesninger. Ifølge en ingeniør som spesialiserer seg på prosessorutvikling, har frykten for tidsforskyvninger ved bruk av TSC lenge vært usanne, og i moderne prosessorer kan denne kilden gi stabile avlesninger i årevis.
Bytte av produksjonsservere hos Netflix til en TSC-kilde resulterte i en 43 % reduksjon i skrivelatens og oppnådde resultater ved bruk av Ubuntu som var 4 ganger raskere enn konfigurasjoner som kjører CentOS med en "xen"-tidskilde. Resultatene av studien ble overført til Amazon, som offisielt anbefalte å bruke standard TSC-tidskilde i AWS EC2-miljøer basert på Xen-hypervisor (kvm-klokke forblir anbefalt i miljøer basert på Nitro-hypervisor).
Kilde: opennet.ru