Analyse af påvirkningen på ydeevnen af den valgte tidskilde i systemet

Brendan Gregg, en af udviklerne af DTrace, der nu arbejder med værktøjer til ydeevneanalyse baseret på BPF i Linux-kernen, har opsummeret sine erfaringer fra problemløsningen med ydeevne, som Netflix stødte på ved migrationen af databasesystemet Cassandra fra CentOS til Ubuntu i Amazon EC2-miljøer baseret på Xen. Efter migreringen steg CPU-belastningen med 30 %, og forsinkelserne ved udførelse af skriveoperationer steg omtrent tilsvarende. Det viste sig, at ydeevnen af applikationer, der intensivt forespørger tidsinformation, er meget afhængig af den valgte tidskilde i systemet.

I starten var årsagen til den nedsatte ydeevne ikke åbenlys, og diagnosticeringen begyndte med at spore den mulige indvirkning fra konstant kørende eller periodisk startede ressourcetunge systemprocesser ved hjælp af værktøjerne top og execsnoop. Men alt pegede på, at ressourceforbruget var steget netop i databasesystemet Cassandra, skrevet i Java. Sammenligningen af profilresultaterne fra to Cassandra-processer, der kørte parallelt i CentOS og Ubuntu og behandlede de samme forespørgsler, viste, at ca. 32 % af al den tid, der blev brugt, gik til kaldet os::javaTimeMillis(), som anvendes til at få information om den aktuelle tid.

Derefter blev der udført et eksperiment, hvor der blev skrevet en simpel applikation i Java, der i en løkke kaldte metoden System.currentTimeMillis() hundrede millioner gange. Kørsel af applikationen viste, at det tog 13 sekunder at udføre i CentOS, mens det tog omkring 68 sekunder i Ubuntu, altså fem gange langsommere. Der blev skrevet et lignende program i C, som kaldte funktionen gettimeofday() hundrede millioner gange, men resultaterne var ens.

Da det blev klart, at problemet skyldtes funktionen til at returnere den aktuelle tid, blev opmærksomheden rettet mod ændring af målinger ved valg af forskellige kilder til præcist tid i systemet. Ifølge indholdet af '/sys/devices/system/clocksource/clocksource0/current_clocksource' blev timeren 'xen' som standard brugt ved opstart af Linux i gæstesystemet. Efter at have ændret tidskilden til 'tsc' blev udførelsestiden for testapplikationen i Ubuntu reduceret fra 68 til 3,3 sekunder, hvilket er 20 gange hurtigere. Derudover blev der udført en test af ydeevnen for tidskilden kvm-clock, 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 $ 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

For at få tiden ved valg af tidskilden TSC anvendes CPU-instruktionen RDTSC, hvis udførelse ikke kræver et systemopkald (instruktionen kræver ikke forhøjede privilegier og afgiver værdien fra den indbyggede tids tæller i CPU'en). Som standard aktiveres TSC ikke, da denne kilde i gamle dage ikke udelukkede gradvis tid drift, som i andre håndtere korrigeres programmæssigt for at opnå mere præcise målinger. Ifølge en ingeniør, der specialiserer sig i processorudvikling, er bekymringerne om tidsforskydninger ved brug af TSC for længst ikke længere relevante og i moderne processorer kan denne kilde give stabile målinger i årevis.

Oversættelse af arbejdsmiljøer servere i Netflix til tidskilden TSC førte til en reduktion af forsinkelser ved skrivning på 43% og opnåede resultater i Ubuntu, der oversteg konfigurationen med CentOS med tidskilden 'xen' fire gange. Resultaterne af den udførte undersøgelse blev overdraget til Amazon, som officielt anbefalede at bruge tidskilden TSC som standard i AWS EC2-miljøer baseret på Hypervisor Xen (i miljøer baseret på Nitro-hypervisoren forbliver kvm-clock anbefalet).

Kilde: opennet.ru

Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere 🔥 Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere | ProHoster