Brendan Gregg, en af udviklerne af DTrace, som i øjeblikket udvikler BPF-baserede ydelsesanalyseværktøjer i Linux-kernen, opsummerede erfaringerne fra at analysere de ydeevneproblemer, som Netflix stødte på ved migrering af Cassandra DBMS fra CentOS til Ubuntu.-miljøer, der kører på Amazon EC2-skyen baseret på Xen. Efter migrering steg CPU-belastningen med 30 %, og forsinkelserne under skriveoperationer steg med omtrent samme mængde. Som det viser sig, afhænger ydeevnen af applikationer, der intensivt anmoder om tidsinformation, meget af den nøjagtige tidskilde, der er valgt i systemet.
Til at begynde med var årsagen til faldet i ydeevne ikke indlysende, og diagnosen begyndte med at overvåge den mulige effekt af konstant kørende eller periodisk lancerede ressourcekrævende systemprocesser ved hjælp af top- og execsnoop-værktøjerne. Men alt tydede på, at ressourceforbruget var steget specifikt i Cassandra DBMS, skrevet i Java. Sammenligning af profilmålingerne for to Cassandra-processer, der kører parallelt på CentOS og Ubuntu, og behandling af de samme forespørgsler, viste, at omkring 32 % af den samlede tid blev brugt på at kalde os::javaTimeMillis(), som bruges til at få oplysninger om det aktuelle tidspunkt .
Herefter blev der udført et eksperiment, hvor der blev skrevet en simpel Java-applikation, der kaldte System.currentTimeMillis()-metoden hundrede millioner gange i en løkke. Kørsel af applikationen viste, at det tog 13 sekunder at gennemføre på CentOS, og omkring 68 sekunder på Ubuntu, dvs. 5 gange langsommere. Et lignende program blev skrevet i C, der kaldte funktionen gettimeofday() hundrede millioner gange, men når det blev udført, blev der opnået lignende resultater.
Da det blev klart, at kilden til problemet var funktionen af at returnere den aktuelle tid, blev opmærksomheden rettet mod ændringer i indikatorer, når man valgte forskellige kilder til nøjagtig tid i systemet. At dømme efter indholdet af "/sys/devices/system/clocksource/clocksource0/current_clocksource", blev "xen"-timeren brugt som standard, når Linux kørte i gæstesystemet. Efter at have ændret tidskilden til "tsc" faldt udførelsestiden for testapplikationen i Ubuntu fra 68 til 3.3 sekunder, dvs. det blev 20 gange hurtigere. Derudover blev der udført en ydelsestest af kvm-ur-tidskilden, som viste en stigning i forsinkelser på 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 bruger 0m38.337s $0ms echo tsc > /sys/devices/system/clocksource/clocksource29.875/current_clocksource $ tid java TimeBench real 0m0s bruger 3.370m0s sys 3.353m0s
For at opnå tidspunktet, når du vælger en TSC-kilde, bruges RDTSC-processorinstruktionen, hvis udførelse ikke kræver et systemkald (instruktionen kræver ikke forhøjede privilegier og producerer en værdi fra tidstælleren indbygget i CPU'en). Som standard er TSC ikke aktiveret, fordi denne kilde i gamle dage ikke udelukkede gradvis tidsdrift, som i andre processorer justeres af software for at opnå mere nøjagtige aflæsninger. Ifølge en ingeniør med speciale i processorudvikling har frygten for tidsforskydninger ved brug af TSC længe været usand, og i moderne processorer kan denne kilde producere stabile aflæsninger i årevis.
Skift af produktionsservere hos Netflix til en TSC-kilde resulterede i en 43 % reduktion i skrivelatens og opnåede resultater ved brug af Ubuntu, der var 4 gange hurtigere end konfigurationer, der kører CentOS med en "xen"-tidskilde. Resultaterne af undersøgelsen blev overført til Amazon, som officielt anbefalede at bruge standard TSC-tidskilden i AWS EC2-miljøer baseret på Xen-hypervisoren (kvm-clock forbliver anbefalet i miljøer baseret på Nitro-hypervisoren).
Kilde: opennet.ru