Բրենդան Գրեգը, DTrace-ի ծրագրավորողներից մեկը, ով ներկայումս մշակում է BPF-ի վրա հիմնված կատարողականի վերլուծության գործիքներ Linux միջուկում, ամփոփել է այն փորձը, որը ձեռք է բերվել վերլուծելով կատարողականի խնդիրները, որոնց բախվել է Netflix-ը Cassandra DBMS-ը CentOS-ից Ubuntu տեղափոխելիս: Amazon EC2 ամպը՝ հիմնված Xen-ի վրա: Միգրացիայից հետո պրոցեսորի ծանրաբեռնվածությունն ավելացել է 30%-ով, իսկ գրելու գործառնությունների ժամանակ ուշացումներն աճել են մոտավորապես նույնքանով: Ինչպես պարզվում է, հավելվածների աշխատանքը, որոնք ինտենսիվորեն պահանջում են ժամանակի մասին տեղեկատվություն, շատ է կախված համակարգում ընտրված ճշգրիտ ժամանակի աղբյուրից:
Սկզբում կատարողականի նվազման պատճառն ակնհայտ չէր, և ախտորոշումը սկսվեց մշտական գործող կամ պարբերաբար գործարկվող ռեսուրսային ինտենսիվ համակարգի գործընթացների հնարավոր ազդեցության մոնիտորինգով, օգտագործելով լավագույն և execsnoop կոմունալ ծառայությունները: Բայց ամեն ինչ ցույց էր տալիս, որ ռեսուրսների սպառումը հատկապես աճել է Java-ով գրված Cassandra DBMS-ում: Համեմատելով CentOS-ում և Ubuntu-ում զուգահեռ ընթացող երկու Cassandra գործընթացների պրոֆիլավորման ցուցանիշները, մշակելով նույն հարցումները, ցույց տվեցին, որ ընդհանուր ժամանակի մոտ 32%-ը ծախսվել է os::javaTimeMillis() կանչելու վրա, որն օգտագործվում է ընթացիկ ժամանակի մասին տեղեկատվություն ստանալու համար: .
Դրանից հետո անցկացվեց փորձ, որտեղ գրվեց մի պարզ Java հավելված, որը ցիկլով հարյուր միլիոն անգամ կոչեց System.currentTimeMillis() մեթոդը: Հավելվածի գործարկումը ցույց տվեց, որ CentOS-ում ավարտելու համար պահանջվել է 13 վայրկյան, իսկ Ubuntu-ում՝ մոտ 68 վայրկյան, այսինքն. 5 անգամ ավելի դանդաղ: Նմանատիպ ծրագիր գրվել է C-ում, որը հարյուր միլիոն անգամ կանչել է gettimeofday() ֆունկցիան, բայց երբ գործարկվել է, ստացվել են նմանատիպ արդյունքներ։
Քանի որ պարզ դարձավ, որ խնդրի աղբյուրը ընթացիկ ժամանակը վերադարձնելու գործառույթն է, համակարգում ճշգրիտ ժամանակի տարբեր աղբյուրներ ընտրելիս ուշադրություն դարձվեց ցուցիչների փոփոխությանը: Դատելով «/sys/devices/system/clocksource/clocksource0/current_clocksource» բովանդակությունից՝ «xen» ժմչփն օգտագործվում էր լռելյայնորեն՝ հյուրերի համակարգում Linux գործարկելիս: Ժամանակի աղբյուրը «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 իրական 1m8.300s օգտատեր $0s 38.337ssm echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ time java TimeBench իրական 29.875m0s օգտվող 0m3.370s sys 0m3.353s
TSC աղբյուր ընտրելիս ժամանակ ստանալու համար օգտագործվում է RDTSC պրոցեսորի հրահանգը, որի կատարման համար համակարգային զանգ չի պահանջվում (հրահանգը չի պահանջում բարձր արտոնություններ և արժեք է արտադրում պրոցեսորի մեջ ներկառուցված ժամանակի հաշվիչից): Լռելյայնորեն, TSC-ն ակտիվացված չէ, քանի որ հին ժամանակներում այս աղբյուրը չէր բացառում ժամանակի աստիճանական շեղումը, որը այլ պրոցեսորներում ճշգրտվում է ծրագրային ապահովման միջոցով՝ ավելի ճշգրիտ ընթերցումներ ստանալու համար: Ըստ պրոցեսորների մշակման մեջ մասնագիտացած ինժեների, TSC-ի օգտագործման ժամանակ ժամանակի փոփոխության մասին մտավախությունները վաղուց չեն համապատասխանում իրականությանը, և ժամանակակից պրոցեսորներում այս աղբյուրը կարող է տարիներ շարունակ կայուն ընթերցումներ առաջացնել:
Արտադրական սերվերները Netflix-ում TSC աղբյուրի փոխարկելը հանգեցրել է գրման հետաձգման 43%-ով կրճատմանը և Ubuntu-ի միջոցով ձեռք բերել արդյունքների, որոնք 4 անգամ ավելի արագ են եղել, քան CentOS-ը «xen» ժամանակի աղբյուրով աշխատող կոնֆիգուրացիաները: Հետազոտության արդյունքները փոխանցվել են Amazon-ին, որը պաշտոնապես խորհուրդ է տվել օգտագործել լռելյայն TSC ժամանակի աղբյուրը AWS EC2 միջավայրերում՝ հիմնված Xen հիպերվիզորի վրա (kvm-clock-ը մնում է առաջարկված Nitro հիպերվիզորի վրա հիմնված միջավայրերում):
Source: opennet.ru