Brendan Gregg-ek, DTrace-ren garatzaileetako batek, BPFn oinarritutako errendimenduaren analisirako tresnak garatzen ari dena Linux nukleoan, Netflix-ek Cassandra DBMS CentOSetik Ubuntura exekutatzen ari diren inguruneak migratzean Netflix-ek aurkitu zituen errendimendu-arazoak aztertzean lortutako esperientzia laburtu zuen. Xen-en oinarritutako Amazon EC2 hodeia. Migrazioaren ondoren, PUZaren karga % 30 handitu zen eta idazketa-eragiketetan atzerapenak kopuru berean handitu ziren. Ikusten denez, denbora-informazioa intentsiboki eskatzen duten aplikazioen errendimendua sisteman hautatutako denbora-iturri zehatzaren araberakoa da.
Hasieran, errendimenduaren jaitsieraren arrazoia ez zen begi-bistakoa izan eta diagnostikoa etengabe exekutatzen diren edo aldian-aldian baliabideak asko erabiltzen dituzten sistema-prozesuek goi-mailako eta execsnoop utilitateak erabiliz abiarazitako prozesuek izan dezaketen eragina kontrolatzen hasi zen. Baina denak adierazten zuen baliabideen kontsumoa hazi zela bereziki Javan idatzitako Cassandra DBMS-n. CentOS eta Ubuntun paraleloan exekutatzen diren Cassandra prozesuen profilaren neurketak alderatuz, kontsulta berdinak prozesatzen, erakutsi zuen denbora osoaren % 32 inguru os::javaTimeMillis() deitzen igaro zela, uneko orduari buruzko informazioa lortzeko erabiltzen dena. .
Honen ostean, esperimentu bat egin zen eta bertan ehun milioi aldiz begizta batean System.currentTimeMillis() metodoa izeneko Java aplikazio sinple bat idatzi zen. Aplikazioa exekutatzeak CentOSen 13 segundo behar zituela osatzeko eta 68 segundo inguru Ubuntun, hau da. 5 aldiz motelagoa. C-n antzeko programa bat idatzi zen gettimeofday() funtzioari ehun milioi aldiz deitzen zion, baina exekutatzean, antzeko emaitzak lortu ziren.
Arazoaren iturria uneko ordua itzultzearen funtzioa zela argi geratu zenez, sistemako denbora zehatzaren iturri desberdinak aukeratzerakoan adierazleen aldaketetara jarri zen arreta. "/sys/devices/system/clocksource/clocksource0/current_clocksource" edukiaren arabera, "xen" tenporizadorea erabiltzen zen lehenespenez Linux sistema gonbidatuan exekutatzen denean. Denbora-iturria "tsc"-ra aldatu ondoren, proba-aplikazioaren exekuzio denbora Ubuntun 68tik 3.3 segundora jaitsi zen, hau da. 20 aldiz azkarragoa bihurtu zen. Gainera, kvm-erlojuaren denbora-iturriaren errendimendu-proba bat egin zen, eta atzerapenak %20 handitu ziren TSCrekin alderatuta. $ 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 benetako 1m8.300s erabiltzailea 0m38.337s $ sys. echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ denbora java TimeBench benetako 29.875m0s erabiltzailea 0m3.370s sys 0m3.353s
TSC iturburua hautatzeko ordua lortzeko, RDTSC prozesadorearen instrukzioa erabiltzen da, zeinaren exekuzioak ez du sistema deirik behar (instrukzio horrek ez du pribilegio handirik behar eta CPUan eraikitako denbora-kontagailutik balio bat sortzen du). Lehenespenez, TSC ez dago aktibatuta, antzina iturri honek ez zuelako pixkanakako denbora-noraeza baztertzen, beste prozesadoreetan softwarearen bidez doitzen baita irakurketa zehatzagoak lortzeko. Prozesadorearen garapenean espezializatutako ingeniari baten arabera, TSC erabiltzean denbora aldaketei buruzko beldurrak ez dira egiazkoak aspalditik eta prozesadore modernoetan iturri honek irakurketa egonkorrak sor ditzake urtetan zehar.
Netflix-en produkzio-zerbitzariak TSC iturri batera aldatzeak idazketa-latentzia %43 murriztu zuen eta Ubuntu erabiliz CentOS exekutatzen duten konfigurazioek baino 4 aldiz azkarragoak izan ziren "xen" denbora-iturburu batekin. Azterketaren emaitzak Amazonera transferitu ziren, eta ofizialki gomendatu zuen Xen hipervisorean oinarritutako AWS EC2 inguruneetan TSC denbora-iturburu lehenetsia erabiltzea (kvm-erlojua Nitro hipervisorean oinarritutako inguruneetan gomendatzen da).
Iturria: opennet.ru