Брендан Грегг, један од програмера ДТраце-а, који тренутно развија алате за анализу перформанси засноване на БПФ-у у Линук кернелу, резимирао је искуство стечено анализом проблема са перформансама на које је Нетфлик наишао приликом миграције Цассандра ДБМС-а са ЦентОС-а на Убунту. Амазон ЕЦ2 облак заснован на Ксен-у. Након миграције, оптерећење ЦПУ-а се повећало за 30%, а кашњења током операција писања су порасла за отприлике исти износ. Како се испоставило, перформансе апликација које интензивно траже информације о времену веома зависе од тачног извора времена одабраног у систему.
У почетку, разлог за смањење перформанси није био очигледан и дијагноза је почела праћењем могућег утицаја стално покренутих или периодично покретаних системских процеса са интензивним ресурсима помоћу топ и екецснооп услужних програма. Али све је указивало да се потрошња ресурса повећала посебно у Цассандра ДБМС, написаном на Јави. Упоређивање метрике профилисања два Цассандра процеса који раде паралелно на ЦентОС-у и Убунту-у, обрађујући исте упите, показало је да је око 32% укупног времена потрошено на позивање ос::јаваТимеМиллис(), који се користи за добијање информација о тренутном времену .
Након овога, спроведен је експеримент у коме је написана једноставна Јава апликација која је назвала Систем.цуррентТимеМиллис() метод сто милиона пута у петљи. Покретање апликације показало је да је за завршетак на ЦентОС-у било потребно 13 секунди, а на Убунту-у око 68 секунди, тј. 5 пута спорије. Сличан програм је написан у Ц-у који је позвао функцију геттимеофдаи() сто милиона пута, али када се изврши, добијају се слични резултати.
Пошто је постало јасно да је извор проблема функција враћања тренутног времена, пажња се окренула променама индикатора при избору различитих извора тачног времена у систему. Судећи по садржају „/сис/девицес/систем/цлоцксоурце/цлоцксоурце0/цуррент_цлоцксоурце“, „кен“ тајмер је подразумевано коришћен када се Линук покреће у систему за госте. После промене извора времена у „тсц“, време извршења тестне апликације у Убунту-у се смањило са 68 на 3.3 секунде, тј. постало је 20 пута брже. Додатно, спроведен је тест перформанси извора времена квм-цлоцк, који је показао повећање кашњења за 20% у поређењу са ТСЦ. $ цат /сис/девицес/систем/цлоцксоурце/цлоцксоурце0/аваилабле_цлоцксоурце кен тсц хпет ацпи_пм $ цат /сис/девицес/систем/цлоцксоурце/цлоцксоурце0/цуррент_цлоцксоурце кен $ тиме јава ТимеБенцх реал 1м8.300с корисник 0м38.337с.сис.0м ецхо тсц > /сис/девицес/систем/цлоцксоурце/цлоцксоурце29.875/цуррент_цлоцксоурце $ тиме јава ТимеБенцх реал 0м0с корисник 3.370м0с сис 3.353м0с
За добијање времена при избору ТСЦ извора користи се инструкција процесора РДТСЦ, за чије извршавање није потребан системски позив (инструкција не захтева повишене привилегије и производи вредност из бројача времена уграђеног у ЦПУ). Подразумевано, ТСЦ није активиран јер у старим временима овај извор није искључивао постепено временско померање, које се код других процесора подешава софтвером како би се постигла тачнија очитавања. Према инжењеру специјализованом за развој процесора, страхови од временских померања при коришћењу ТСЦ-а су дуго били нетачни и код савремених процесора овај извор може да даје стабилна очитавања годинама.
Пребацивање производних сервера на Нетфлик-у на ТСЦ извор резултирало је смањењем кашњења писања за 43% и постигнутим резултатима коришћењем Убунту-а који су били 4 пута бржи од конфигурација које користе ЦентОС са „кен” извором времена. Резултати студије су пренети на Амазон, који је званично препоручио коришћење подразумеваног ТСЦ извора времена у АВС ЕЦ2 окружењима заснованим на Ксен хипервизору (квм-цлоцк остаје препоручен у окружењима заснованим на Нитро хипервизору).
Извор: опеннет.ру