Brendan Gregg, een van de ontwikkelaars van DTrace, die momenteel tools voor prestatie-analyse op basis van BPF in de Linux-kernel ontwikkelt, heeft de ervaringen samengevat die zijn verkregen tijdens de analyse van prestatieproblemen waarmee Netflix werd geconfronteerd bij de migratie van de Cassandra-database van CentOS naar Ubuntu in omgevingen die draaien op Amazon EC2 met Xen. Na de migratie steeg de belasting op de CPU met 30% en stegen de vertragingen bij schrijfoperaties met ongeveer dezelfde hoeveelheid. Het bleek dat de prestaties van applicaties die sterk afhankelijk zijn van tijdsinformatie, sterk afhankelijk zijn van de gekozen bron voor exacte tijd binnen het systeem.
In het begin was de oorzaak van de prestatievermindering niet duidelijk en begon de diagnose met het volgen van de mogelijke invloed van voortdurend draaiende of periodiek startende resource-intensieve systeemprocessen met behulp van de tools top en execsnoop. Maar alles wees erop dat het resourceverbruik juist in de Cassandra-database, geschreven in Java, was toegenomen. Een vergelijking van de profileringsgegevens van de twee Cassandra-processen, die parallel draaiden op CentOS en Ubuntu en dezelfde verzoeken verwerkten, toonde aan dat ongeveer 32% van de totale tijd werd besteed aan het aanroepen van os::javaTimeMillis(), dat wordt gebruikt voor het verkrijgen van actuele tijdinformatie.
Daarna werd er een experiment uitgevoerd waarbij een eenvoudige applicatie in Java werd geschreven die in een lus honderd miljoen keer de methode System.currentTimeMillis() aanroept. De uitvoering van de applicatie toonde aan dat het onder CentOS 13 seconden nodig had om te draaien, terwijl het onder Ubuntu ongeveer 68 seconden kostte, dat is 5 keer langzamer. Een vergelijkbaar programma in C, dat honderd miljoen keer de functie gettimeofday() aanriep, leverde echter soortgelijke resultaten op.
Aangezien het duidelijk werd dat de oorzaak van het probleem de functie voor het ophalen van de huidige tijd was, werd de aandacht gericht op het aanpassen van de parameters bij het kiezen van verschillende tijdbronnen in het systeem. Uit de inhoud van "/sys/devices/system/clocksource/clocksource0/current_clocksource" blijkt dat standaard bij het opstarten van Linux in het gastensysteem de "xen" timer werd gebruikt. Na het wijzigen van de tijdsource naar "tsc" daalde de uitvoertijd van de testtoepassing in Ubuntu van 68 naar 3,3 seconden, wat betekent dat de uitvoering 20 keer sneller werd. Daarnaast werd er een prestatietest uitgevoerd voor de tijdsource kvm-clock, die een toename van de latentie met 20% toonde in vergelijking met TSC. $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ time java TimeBench real 1m8.300s user 0m38.337s sys 0m29.875s $ echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ time java TimeBench real 0m3.370s user 0m3.353s sys 0m0.026s
Voor het verkrijgen van tijd bij het kiezen van de TSC-bron wordt de processorinstructie RDTSC gebruikt, waarvan de uitvoering geen systeemaanroep vereist (de instructie vereist geen verhoogde privileges en geeft een waarde uit de ingebouwde tijdteller van de CPU). Standaard wordt TSC niet geactiveerd omdat in vroegere tijden deze bron geen geleidelijke tijdsdrift uitsloot, welke in andere handlers programmatisch wordt gecorrigeerd voor meer nauwkeurige metingen. Volgens een ingenieur die gespecialiseerd is in processorontwikkeling, zijn de zorgen over tijdverschuivingen bij het gebruik van TSC allang verouderd en in moderne processors deze bron kan jarenlang stabiele waarden geven.
Werkt overzetten servers in Netflix naar de TSC-bron leidde tot een verlaging van de latentie bij het schrijven met 43% en tot resultaten in Ubuntu die 4 keer beter waren dan de configuratie met CentOS met de "xen" tijdsource. De resultaten van het onderzoek zijn doorgestuurd naar Amazon, dat officieel aanbeveelt om in AWS EC2-omgevingen op basis van de Xen-hypervisor standaard de TSC-tijdsource te gebruiken (in omgevingen op basis van de Nitro-hypervisor blijft kvm-clock aanbevolen).
Bron: opennet.ru
