Анализ на въздействието върху производителността на източника на време, избран в системата

Брендън Грег, един от разработчиците на DTrace, който в момента разработва BPF-базирани инструменти за анализ на производителността в ядрото на Linux, обобщи опита, натрупан от анализирането на проблемите с производителността, които Netflix срещна при мигрирането на Cassandra DBMS от CentOS към Ubuntu. облакът Amazon EC2, базиран на Xen. След миграцията натоварването на процесора се увеличи с 30% и закъсненията по време на операциите за запис се увеличиха с приблизително същата сума. Както се оказва, производителността на приложенията, които интензивно изискват информация за времето, зависи много от точния източник на време, избран в системата.

Първоначално причината за намаляването на производителността не беше очевидна и диагностиката започна с наблюдение на възможното въздействие на постоянно работещи или периодично стартирани системни процеси, изискващи големи ресурси, с помощта на помощните програми top и execsnoop. Но всичко показваше, че потреблението на ресурси се е увеличило специално в СУБД Cassandra, написана на Java. Сравняването на показателите за профилиране на два процеса Cassandra, работещи паралелно на CentOS и Ubuntu, обработващи едни и същи заявки, показа, че около 32% от общото време е изразходвано за извикване на os::javaTimeMillis(), което се използва за получаване на информация за текущото време .

След това беше проведен експеримент, в който беше написано просто Java приложение, което извиква метода System.currentTimeMillis() сто милиона пъти в цикъл. Пускането на приложението показа, че завършването му отнема 13 секунди на CentOS и около 68 секунди на Ubuntu, т.е. 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 $ време java TimeBench реален 1m8.300s потребител 0m38.337s sys 0m29.875s $ echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ време java TimeBench реален 0m3.370s потребител 0m3.353s sys 0m0.026s

За получаване на времето при избор на източник на TSC се използва инструкцията на процесора RDTSC, чието изпълнение не изисква системно извикване (инструкцията не изисква повишени привилегии и произвежда стойност от брояча на времето, вграден в процесора). По подразбиране TSC не е активиран, тъй като в старите дни този източник не изключваше постепенното отклонение във времето, което в други процесори се настройва от софтуера, за да се постигнат по-точни показания. Според инженер, специализиран в разработката на процесори, страховете за изместване на времето при използване на TSC отдавна не са верни и в съвременните процесори този източник може да дава стабилни показания в продължение на години.

Превключването на производствени сървъри в Netflix към източник на TSC доведе до 43% намаление на латентността при запис и постигна резултати с помощта на Ubuntu, които бяха 4 пъти по-бързи от конфигурации, работещи с CentOS с източник на време „xen“. Резултатите от проучването бяха прехвърлени на Amazon, който официално препоръча използването на източника на време TSC по подразбиране в AWS EC2 среди, базирани на Xen хипервайзор (kvm-clock остава препоръчан в среди, базирани на Nitro хипервайзор).

Източник: opennet.ru