Brendans Gregs, viens no DTrace izstrādātājiem, kurš šobrīd Linux kodolā izstrādā uz BPF balstītus veiktspējas analīzes rīkus, apkopoja pieredzi, kas gūta, analizējot veiktspējas problēmas, ar kurām Netflix saskārās, migrējot Cassandra DBVS no CentOS uz Ubuntu vidēm. Amazon EC2 mākonis, kura pamatā ir Xen. Pēc migrācijas CPU slodze palielinājās par 30%, un aizkaves rakstīšanas operāciju laikā palielinājās par aptuveni tikpat daudz. Kā izrādās, to aplikāciju darbība, kuras intensīvi pieprasa laika informāciju, ļoti lielā mērā ir atkarīga no precīzā sistēmā izvēlētā laika avota.
Sākumā veiktspējas samazināšanās iemesls nebija acīmredzams, un diagnoze sākās ar nepārtraukti darbojošos vai periodiski palaistu resursietilpīgu sistēmas procesu iespējamās ietekmes uzraudzību, izmantojot top un execsnoop utilītas. Bet viss liecināja, ka resursu patēriņš ir īpaši palielinājies Java valodā rakstītajā Cassandra DBVS. Salīdzinot profilēšanas metriku diviem Cassandra procesiem, kas darbojas paralēli CentOS un Ubuntu, apstrādājot vienus un tos pašus vaicājumus, atklājās, ka aptuveni 32% no kopējā laika tika pavadīti, izsaucot os::javaTimeMillis(), ko izmanto, lai iegūtu informāciju par pašreizējo laiku. .
Pēc tam tika veikts eksperiments, kurā tika uzrakstīta vienkārša Java lietojumprogramma, kas cilpā simts miljonus reižu izsauca metodi System.currentTimeMillis(). Lietojumprogrammas palaišana parādīja, ka CentOS aizpildīšana prasīja 13 sekundes, bet Ubuntu - aptuveni 68 sekundes, t.i. 5 reizes lēnāk. Līdzīga programma tika uzrakstīta C valodā, kas simts miljonus reižu izsauca funkciju gettimeofday(), taču, to izpildot, tika iegūti līdzīgi rezultāti.
Tā kā kļuva skaidrs, ka problēmas cēlonis ir pašreizējā laika atgriešanas funkcija, izvēloties dažādus precīzā laika avotus sistēmā, uzmanība tika pievērsta rādītāju izmaiņām. Spriežot pēc “/sys/devices/system/clocksource/clocksource0/current_clocksource” satura, “xen” taimeris tika izmantots pēc noklusējuma, kad viesa sistēmā darbojas Linux. Pēc laika avota maiņas uz "tsc" Ubuntu testa lietojumprogrammas izpildes laiks samazinājās no 68 līdz 3.3 sekundēm, t.i. tas kļuva 20 reizes ātrāks. Papildus tika veikts kvm-pulksteņa laika avota veiktspējas tests, kas uzrādīja aizkaves pieaugumu par 20%, salīdzinot ar TSC. $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ laiks java TimeBench reāls 1m8.300s lietotājs 0m38.337s0 sys. echo tsc > /sys/devices/system/clocksource/clocksource29.875/current_clocksource $ laiks java TimeBench reāls 0m0s lietotājs 3.370m0s sys 3.353m0s
Lai iegūtu laiku, izvēloties TSC avotu, tiek izmantota RDTSC procesora instrukcija, kuras izpildei nav nepieciešams sistēmas izsaukums (instrukcija neprasa paaugstinātas privilēģijas un rada vērtību no CPU iebūvētā laika skaitītāja). Pēc noklusējuma TSC nav aktivizēts, jo vecos laikos šis avots neizslēdza pakāpenisku laika novirzi, ko citos procesoros pielāgo programmatūra, lai iegūtu precīzākus rādījumus. Saskaņā ar inženiera, kas specializējas procesoru izstrādē, bažas par laika nobīdēm, lietojot TSC, jau sen ir bijušas nepatiesas, un mūsdienu procesoros šis avots var radīt stabilus rādījumus gadiem ilgi.
Pārslēdzot Netflix ražošanas serverus uz TSC avotu, par 43% tika samazināts rakstīšanas latentums un sasniegti rezultāti, izmantojot Ubuntu, kas bija 4 reizes ātrāki nekā konfigurācijas, kurās darbojas CentOS ar “xen” laika avotu. Pētījuma rezultāti tika nodoti Amazon, kas oficiāli ieteica izmantot noklusējuma TSC laika avotu AWS EC2 vidēs, kuru pamatā ir Xen hipervizors (vidēs, kuru pamatā ir Nitro hipervizors, joprojām ir ieteicams lietot kvm pulksteni).
Avots: opennet.ru