Брэндан Грег (Brendan Gregg), адзін з распрацоўнікаў DTrace, цяпер які развівае сродкі для аналізу прадукцыйнасці на базе BPF у ядры Linux, абагульніў досвед, атрыманы падчас разбору праблем з прадукцыйнасцю, з якімі кампанія Netflix сутыкнулася пры перакладзе СКБД Cassandra c CentOS на Ubu асяроддзі, якія выконваюцца ў воблаку Amazon EC2 на базе Xen. Пасля міграцыі нагрузка на CPU павялічылася на 30% і прыкладна на столькі ж узраслі затрымкі пры выкананні аперацый запісу. Як аказалася, прадукцыйнасць прыкладанняў, інтэнсіўна запытваюць інфармацыю аб часе, вельмі моцна залежыць ад абранага ў сістэме крыніцы дакладнага часу.
Спачатку прычына зніжэння прадукцыйнасці была не відавочная і дыягностыка пачалася з адсочвання магчымага ўплыву пастаянна працуюць або перыядычна запускаюцца рэсурсаёмістых сістэмных працэсаў пры дапамозе ўтыліт top і execsnoop. Але ўсё паказвала на тое, што спажыванне рэсурсаў павялічылася менавіта ў СКБД Cassandra, напісанай на мове Java. Параўнанне паказчыкаў прафілявання двух працэсаў Cassandra, раўналежна запушчаных у CentOS і Ubuntu і якія апрацоўваюць адны і тыя ж запыты, паказала, што каля 32% усяго часу марнуецца на выклік os::javaTimeMillis(), выкарыстоўваны для атрымання інфармацыі аб бягучым часе.
Пасля гэтага быў праведзены эксперымент, падчас якога было напісана простае прыкладанне на мове Java, у цыкле выклікалае сто мільёнаў разоў метад System.currentTimeMillis(). Запуск прыкладання паказаў, што ў CentOS для яго выканання запатрабавалася 13 секунд, а ў Ubuntu – каля 68 секунд, г.зн. у 5 разоў павольней. На мове Сі была напісана падобная праграма, сто мільёнаў разоў якая выклікае функцыю gettimeofday(), але пры яе выкананні былі атрыманы аналагічныя вынікі.
Бо стала ясна, што крыніцай праблемы з'яўляецца функцыя звароту бягучага часу, увага пераключылася на змену паказчыкаў пры выбары ў сістэме розных крыніц дакладнага часу. Мяркуючы па змесціва "/sys/devices/system/clocksource/clocksource0/current_clocksource" па змаўчанні пры запуску Linux у гасцёўні сістэме выкарыстоўваўся таймер "xen". Пасля змены крыніцы часу на "tsc" час выканання тэставага прыкладання ў Ubuntu паменшылася з 68 да 3.3 секунд, г.зн. стала хутчэй у 20 разоў. Дадаткова быў праведзены тэст прадукцыйнасці крыніцы часу kvm-clock, які паказаў павелічэнне затрымак на 20% у параўнанні з 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.337 echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ time java TimeBench real 29.875m0s user 0m3.370s sys 0m3.353s
Для атрымання часу пры выбары крыніцы TSC выкарыстоўваецца працэсарная інструкцыя RDTSC, выкананне якой не патрабуе здзяйсненне сістэмнага выкліку (інструкцыя не патрабуе падвышаных прывілеяў і выдае значэнне з убудаванага ў CPU лічыльніка часу). Па змаўчанні TSC не актывуецца бо ў былыя часы дадзеная крыніца не выключаў паступовы дрэйф часу, які ў іншых апрацоўшчыках карэктуецца праграмна для дасягнення больш дакладных паказанняў. Па меркаванні інжынера, які спецыялізуецца на распрацоўцы працэсараў, асцярогі аб зрухах часу пры выкарыстанні TSC ужо даўно не адпавядаюць рэчаіснасці і ў сучасных працэсарах дадзеная крыніца можа гады выдаваць стабільныя паказанні.
Перавод працоўных сервераў у Netflix на крыніцу TSC прывёў да зніжэння затрымак пры запісе на 43% і дасягненню пры выкарыстанні Ubuntu вынікаў, у 4 разу праўзыходных канфігурацыі з CentOS з крыніцай часу "xen". Вынікі праведзенага даследавання былі перададзены кампаніі Amazon, якая афіцыйна рэкамендавала ў асяроддзі AWS EC2 на базе гіпервізара Xen выкарыстоўваць па змаўчанні крыніца часу TSC (у асяроддзі на базе гіпервізара Nitro застаецца рэкамендаваны kvm-clock).
Крыніца: opennet.ru