Brendan Gregg, unu el la programistoj de DTrace, kiu nuntempe disvolvas BPF-bazitajn rendimentajn analizojn en la Linukso-kerno, resumis la sperton akiritan de analizado de la rendimentaj problemoj kiujn Netflix renkontis dum migrado de la Cassandra DBMS de CentOS al Ubuntu. la Amazon EC2-nubo bazita sur Xen. Post migrado, la CPU-ŝarĝo pliiĝis je 30% kaj la prokrastoj dum skribaj operacioj pliiĝis je proksimume la sama kvanto. Kiel rezultas, la agado de aplikaĵoj, kiuj intense petas tempinformojn, tre dependas de la ĝusta tempofonto elektita en la sistemo.
Komence, la kialo de la malkresko de rendimento ne estis evidenta kaj la diagnozo komenciĝis per monitorado de la ebla efiko de konstante kurado aŭ periode lanĉitaj rimed-intensaj sistemaj procezoj uzante la suprajn kaj execsnoop-servaĵojn. Sed ĉio indikis, ke la konsumo de rimedoj pliiĝis specife en la Cassandra DBMS, skribita en Java. Komparante la profilajn metrikojn de du Cassandra-procezoj kurantaj paralele sur CentOS kaj Ubuntu, prilaborante la samajn demandojn, montris, ke ĉirkaŭ 32% de la tuta tempo pasigis voki os::javaTimeMillis(), kiu estas uzata por akiri informojn pri la nuna tempo. .
Post tio, eksperimento estis farita en kiu simpla Java aplikaĵo estis skribita kiu nomis la System.currentTimeMillis() metodo cent milionoj da fojoj en buklo. Ruli la aplikaĵon montris, ke necesas 13 sekundoj por kompletigi sur CentOS, kaj proksimume 68 sekundoj ĉe Ubuntu, t.e. 5 fojojn pli malrapida. Simila programo estis skribita en C, kiu vokis la funkcion gettimeofday() cent milionojn da fojoj, sed kiam ĝi estis efektivigita, similaj rezultoj estis akiritaj.
Ĉar evidentiĝis, ke la fonto de la problemo estis la funkcio redoni la nunan tempon, atento turnis sin al ŝanĝoj en indikiloj elektante malsamajn fontojn de ĝusta tempo en la sistemo. Juĝante laŭ la enhavo de "/sys/devices/system/clocksource/clocksource0/current_clocksource", la "xen" tempigilo estis uzata defaŭlte dum funkciado de Linukso en la gastsistemo. Post ŝanĝado de la tempofonto al "tsc", la ekzekuttempo de la testa aplikaĵo en Ubuntu malpliiĝis de 68 al 3.3 sekundoj, t.e. ĝi fariĝis 20 fojojn pli rapide. Plie, spektaklotesto de la kvm-horloĝa tempofonto estis aranĝita, kiu montris pliiĝon en prokrastoj je 20% kompare kun TSC. $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ tempo java TimeBench reala 1m8.300s uzanto 0m38.337s $ sys. echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ tempo java TimeBench reala 29.875m0s uzanto 0m3.370s sys 0m3.353s
Por akiri la tempon dum elektado de TSC-fonto, la RDTSC-procesinstrukcio estas uzita, kies ekzekuto ne postulas sistemvokon (la instrukcio ne postulas levitajn privilegiojn kaj produktas valoron de la tempo-nombrilo konstruita en la CPU). Defaŭlte, TSC ne estas aktivigita ĉar en la malnovaj tempoj ĉi tiu fonto ne ekskludis laŭpaŝan tempodrivon, kiu en aliaj procesoroj estas ĝustigita de programaro por atingi pli precizajn legadojn. Laŭ inĝeniero specialiĝanta pri procesoro-disvolviĝo, timoj pri tempoŝanĝoj dum uzado de TSC estas delonge malveraj kaj en modernaj procesoroj ĉi tiu fonto povas produkti stabilajn legaĵojn dum jaroj.
Ŝanĝi produktadservilojn ĉe Netflix al TSC-fonto rezultigis 43%-redukton de skriba latenco kaj atingis rezultojn uzante Ubuntu, kiuj estis 4 fojojn pli rapidaj ol agordoj kurantaj CentOS kun "xen" tempofonto. La rezultoj de la studo estis transdonitaj al Amazon, kiu oficiale rekomendis uzi la defaŭltan TSC-tempan fonton en AWS EC2-medioj bazitaj sur la hiperviziero Xen (kvm-horloĝo restas rekomendita en medioj bazitaj sur la hiperviziero Nitro).
fonto: opennet.ru