Brendan Gregg, ien fan 'e ûntwikkelders fan DTrace, dy't op it stuit BPF-basearre ark foar prestaasjesanalyse yn' e Linux-kernel ûntwikkelet, gearfette de ûnderfining opdien út it analysearjen fan de prestaasjesproblemen dy't Netflix tsjinkaam by it migrearjen fan de Cassandra DBMS fan CentOS nei Ubuntu. de Amazon EC2 wolk basearre op Xen. Nei migraasje is de CPU-lading mei 30% tanommen en de fertragingen by skriuwoperaasjes tanommen mei sawat itselde bedrach. Sa't bliken docht, hinget de prestaasjes fan applikaasjes dy't yntinsyf tiidynformaasje yntinsyf oanfreegje ôf fan 'e krekte tiidboarne dy't yn it systeem selektearre is.
Yn it earstoan wie de reden foar de fermindering fan prestaasjes net dúdlik en de diagnoaze begon mei it kontrolearjen fan de mooglike ynfloed fan konstant rinnende of periodyk lansearre boarne-yntinsive systeemprosessen mei help fan de top- en execsnoop-nutsbedriuwen. Mar alles joech oan dat boarneferbrûk spesifyk tanommen wie yn 'e Cassandra DBMS, skreaun yn Java. It fergelykjen fan de profilearringsmetriken fan twa Cassandra-prosessen dy't parallel rinne op CentOS en Ubuntu, it ferwurkjen fan deselde fragen, die bliken dat sawat 32% fan 'e totale tiid waard bestege oan it oanroppen fan os :: javaTimeMillis(), dat wurdt brûkt om ynformaasje te krijen oer de hjoeddeistige tiid .
Hjirnei waard in eksperimint útfierd wêryn in ienfâldige Java-applikaasje skreaun waard dy't de System.currentTimeMillis() metoade hûndert miljoen kear yn in lus neamde. It útfieren fan de applikaasje liet sjen dat it 13 sekonden duorre om te foltôgjen op CentOS, en sawat 68 sekonden op Ubuntu, d.w.s. 5 kear stadiger. In ferlykber programma waard skreaun yn C dat de funksje gettimeofday() hûndert miljoen kear neamde, mar as it útfierd waard, waarden ferlykbere resultaten krigen.
Sûnt it dúdlik waard dat de boarne fan it probleem de funksje wie fan it werombringen fan 'e aktuele tiid, gie de oandacht nei feroaringen yn yndikatoaren by it kiezen fan ferskate boarnen fan krekte tiid yn it systeem. Beoardielje nei de ynhâld fan "/sys/devices/system/clocksource/clocksource0/current_clocksource", waard de "xen" timer standert brûkt by it útfieren fan Linux yn it gastsysteem. Nei it feroarjen fan de tiidboarne nei "tsc", fermindere de útfieringstiid fan 'e testapplikaasje yn Ubuntu fan 68 nei 3.3 sekonden, d.w.s. it waard 20 kear flugger. Derneist waard in prestaasjestest fan 'e kvm-kloktiidboarne útfierd, dy't in ferheging fan fertragingen mei 20% toande yn ferliking mei TSC. $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ tiid java TimeBench real 1m8.300s brûker 0m38.337s $0ms29.875 echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ tiid java TimeBench real 0m3.370s brûker 0m3.353s sys 0m0.026s
Om de tiid te krijen by it selektearjen fan in TSC-boarne, wurdt de RDTSC-prosessorynstruksje brûkt, wêrfan de útfiering gjin systeemoprop fereasket (de ynstruksje fereasket gjin ferhege privileezjes en produsearret in wearde út 'e tiidteller dy't yn 'e CPU ynboud is). Standert is TSC net aktivearre, om't yn 'e âlde dagen dizze boarne in graduele tiiddrift net útslút, dy't yn oare processors wurdt oanpast troch software om krekter lêzingen te berikken. Neffens in yngenieur dy't spesjalisearre is yn prosessorûntwikkeling, binne eangsten oer tiidferskowingen by it brûken fan TSC al lang net wier en yn moderne prosessoren kin dizze boarne jierrenlang stabile lêzingen produsearje.
It wikseljen fan produksjeservers by Netflix nei in TSC-boarne resultearre yn in 43% reduksje yn skriuwwachttiid en berikke resultaten mei Ubuntu dy't 4 kear rapper wiene dan konfiguraasjes dy't CentOS draaie mei in "xen" tiidboarne. De resultaten fan 'e stúdzje waarden oerdroegen oan Amazon, dy't offisjeel oanrikkemandearre it brûken fan de standert TSC-tiidboarne yn AWS EC2-omjouwings basearre op de Xen-hypervisor (kvm-klok bliuwt oanrikkemandearre yn omjouwings basearre op de Nitro-hypervisor).
Boarne: opennet.ru