Brendan Gregg, en av utvecklarna av DTrace, som för närvarande utvecklar BPF-baserade prestandaanalysverktyg i Linux-kärnan, sammanfattade erfarenheterna från att analysera de prestandaproblem som Netflix stötte på när jag migrerade Cassandra DBMS från CentOS till Ubuntu.-miljöer som körs på Amazon EC2-molnet baserat på Xen. Efter migreringen ökade CPU-belastningen med 30 % och förseningarna under skrivoperationer ökade med ungefär samma mängd. Som det visar sig beror prestandan för applikationer som intensivt begär tidsinformation väldigt mycket på den exakta tidskällan som valts i systemet.
Till en början var orsaken till minskningen av prestanda inte uppenbar och diagnosen började med att övervaka den möjliga effekten av ständigt pågående eller periodiskt lanserade resurskrävande systemprocesser med hjälp av top- och execsnoop-verktygen. Men allt tydde på att resursförbrukningen hade ökat specifikt i Cassandra DBMS, skrivet i Java. Genom att jämföra profileringsmåtten för två Cassandra-processer som körs parallellt på CentOS och Ubuntu, bearbetning av samma frågor, visade det sig att cirka 32 % av den totala tiden gick åt till att anropa os::javaTimeMillis(), som används för att få information om den aktuella tiden .
Efter detta genomfördes ett experiment där en enkel Java-applikation skrevs som kallade System.currentTimeMillis()-metoden hundra miljoner gånger i en loop. Att köra applikationen visade att det tog 13 sekunder att slutföra på CentOS, och cirka 68 sekunder på Ubuntu, d.v.s. 5 gånger långsammare. Ett liknande program skrevs i C som kallade gettimeofday()-funktionen hundra miljoner gånger, men när det kördes erhölls liknande resultat.
Eftersom det blev tydligt att källan till problemet var funktionen att returnera den aktuella tiden, vändes uppmärksamheten mot förändringar i indikatorer vid val av olika källor för exakt tid i systemet. Att döma av innehållet i "/sys/devices/system/clocksource/clocksource0/current_clocksource", användes "xen"-timern som standard när Linux kördes i gästsystemet. Efter att ha ändrat tidskällan till "tsc" minskade exekveringstiden för testapplikationen i Ubuntu från 68 till 3.3 sekunder, d.v.s. det blev 20 gånger snabbare. Dessutom genomfördes ett prestandatest av kvm-klocktidskällan, vilket visade en ökning av förseningar med 20 % jämfört 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 användare 0m38.337s $0m echo tsc > /sys/devices/system/clocksource/clocksource29.875/current_clocksource $ tid java TimeBench real 0m0s användare 3.370m0s sys 3.353m0s
För att erhålla tiden vid val av en TSC-källa används RDTSC-processorinstruktionen, vars exekvering inte kräver ett systemanrop (instruktionen kräver inte förhöjda privilegier och producerar ett värde från tidsräknaren inbyggd i CPU). Som standard är TSC inte aktiverat eftersom denna källa förr i tiden inte uteslöt gradvis tidsdrift, som i andra processorer justeras av programvara för att uppnå mer exakta avläsningar. Enligt en ingenjör specialiserad på processorutveckling har farhågor om tidsförskjutningar vid användning av TSC länge varit osanna och i moderna processorer kan denna källa ge stabila avläsningar i åratal.
Att byta produktionsservrar på Netflix till en TSC-källa resulterade i en 43% minskning av skrivfördröjningen och uppnådde resultat med Ubuntu som var 4 gånger snabbare än konfigurationer som kör CentOS med en "xen"-tidskälla. Resultaten av studien överfördes till Amazon, som officiellt rekommenderade att använda standard TSC-tidskällan i AWS EC2-miljöer baserade på Xen-hypervisorn (kvm-klocka förblir rekommenderad i miljöer baserade på Nitro-hypervisorn).
Källa: opennet.ru