Brendan Gregg, një nga zhvilluesit e DTrace, tani duke avancuar mjete për analizën e performancës bazuar në BPF në bërthamën Linux, përmbledh përvojën që u fitua gjatë zgjidhjes së problemeve me performancën që kompania Netflix përballi gjatë kalimit të bazës së të dhënave Cassandra nga CentOS në Ubuntu në ambientet që funksiononin në Amazon EC2 në bazë të Xen. Pas migrimit, ngarkesa në CPU u rrit me 30% dhe nga aq sa ndodhi rritja e vonesave gjatë ekzekutimit të operacioneve të shkrimit. Siç rezultoi, performanca e aplikacioneve që kërkonin informacion në lidhje me kohën varietet thellësisht nga burimi i saktë i kohës i zgjedhur në sistem.
Fillimisht, shkaku i rënies së performancës nuk ishte i qartë dhe diagnostika filloi me ndjekjen e ndikimit të mundshëm të proceseve sistemike që konsumonin burime, të cilat funksiononin vazhdimisht ose i fillonin sporadikisht, duke përdorur mjete si top dhe execsnoop. Por gjithçka tregonte se konsumi i burimeve u rrit pikërisht në bazën e të dhënave Cassandra, e shkruar në gjuhën Java. Krahasimi i treguesve të profilizimit të dy proceseve Cassandra, të ekzekutuara paralelisht në CentOS dhe Ubuntu dhe që përpunonin të njëjtat kërkesa, tregoi se rreth 32% e gjithë kohës kalonte në thirrjen e os::javaTimeMillis(), e cila përdoret për të marrë informacion rreth kohës aktuale.
Pas kësaj, u realizua një eksperiment, ku u shkrua një aplikacion i thjeshtë në gjuhën Java, i cili thërriste 100 milion herë metodën System.currentTimeMillis(). Ekzekutimi i aplikacionit tregoi se në CentOS ishin të nevojshme 13 sekonda për ta realizuar, ndërsa në Ubuntu rreth 68 sekonda, pra ishte 5 herë më ngadalë. Një program i ngjashëm u shkrua në gjuhën C, që thërriste 100 milion herë funksionin gettimeofday(), por gjatë ekzekutimit të tij u morën rezultate të ngjashme.
Duke qartësohet se burimi i problemës është funksioni i kthimit të kohës aktuale, vëmendja u kthye te ndryshimet në indicatoret gjatë zgjedhjes së burimeve të ndryshme të saktësisë së kohës në sistem. Sipas përmbajtjes së "\/sys\/devices\/system\/clocksource\/clocksource0\/current_clocksource", nga default, gjatë nisjes së Linux në sistemin e përbashkët, u përdor timeri "xen". Pas ndryshimit të burimit të kohës në "tsc", koha e ekzekutimit të aplikacionit testues në Ubuntu u ul nga 68 në 3.3 sekonda, që do të thotë se u përshpejtua 20 herë. Gjithashtu, u krye një test i performancës së burimit të kohës kvm-clock, i cili tregoi një rritje të vonesave me 20%, krahasuar me 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
Për të marrë kohën duke zgjedhur burimin TSC, përdoret instruksioni i procesorit RDTSC, ekzekutimi i të cilit nuk kërkon kryerjen e një thirrjeje të sistemit (instruksioni nuk kërkon privilegje të larta dhe jep një vlerë nga numëruesi i kohës të integruar në CPU). Në mënyrë default, TSC nuk aktivizohet pasi në të kaluarën ky burim nuk përjashtonte drifti gradual të kohës, i cili në trajtues të tjerë korrigjohet në mënyrë softuerike për të arritur lexime më të sakta. Sipas një inxhinieri që specializohet në zhvillimin e procesorëve, shqetësimet mbi shkarjet e kohës duke përdorur TSC për një kohë të gjatë nuk janë më në përputhje me realitetin dhe procesorët modernë ky burim mund të japë tregues të qëndrueshëm për vite me radhë.
Përkthimi i punës serverësh në Netflix në burimin TSC çoi në uljen e vonesave gjatë regjistrimit me 43% dhe arritjen e rezultateve në Ubuntu që janë 4 herë më të mira se konfiguratat me CentOS me burimin e kohës "xen". Rezultatet e studimit të kryer iu kaluan kompanisë Amazon, e cila rekomandoi zyrtarisht në mjediset AWS EC2 mbi hipervizorin Xen që të përdorej burimi i kohës TSC si default (në mjediset mbi hipervizorin Nitro mbetet e rekomanduar kvm-clock).
Burimi: opennet.ru
