Брендън Грег (Brendan Gregg), един от разработчиците на DTrace, в момента развиваща средства за анализ на производителността, базирани на BPF в ядрото на Linux, обобщи опита, получен по време на разискването на проблемите с производителността, с които компания Netflix се сблъска при миграцията на СУБД Cassandra от CentOS на Ubuntu в облачните среди на Amazon EC2, базирани на Xen. След миграцията натоварването на CPU нарасна с 30% и приблизително толкова също нараснаха забавянията при изпълнението на операциите за запис. Оказа се, че производителността на приложенията, интензивно запитващи информация за времето, зависи изключително много от избора на източника на точно време в системата.
Първоначално причината за намаляването на производителността не беше очевидна и диагностицирането започна с проследяване на възможното влияние на постоянно работещите или периодично стартираните системни процеси с висока консумация на ресурси, използвайки утилитите top и execsnoop. Но всичко сочеше, че потреблението на ресурси е нараснало именно в СУБД Cassandra, написана на Java. Сравнението на показателите за профилиране на два процеса на Cassandra, паралелно стартирани в CentOS и Ubuntu и обработващи едни и същи заявки, показа, че около 32% от всичкото време се използва за извикване на os::javaTimeMillis(), който се използва за получаване на информация за текущото време.
След това беше проведен експеримент, при който беше написано просто приложение на Java, което в цикъл извиква сто милиона пъти метода System.currentTimeMillis(). Стартирането на приложението показа, че в CentOS за неговото изпълнение са били необходими 13 секунди, а в Ubuntu — около 68 секунди, т.е. с 5 пъти по-бавно. На C беше написана подобна програма, която извиква функцията 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.337s sys 0m29.875s $ echo tsc > \/sys\/devices\/system\/clocksource\/clocksource0\/current_clocksource $ time java TimeBench real 0m3.370s user 0m3.353s sys 0m0.026s
За получаване на времето при избор на източник TSC се използва процесорната инструкция RDTSC, изпълнението на която не изисква извършване на системен повик (инструкцията не изисква повишени привилегии и дава стойност от вграденото в CPU времево броене). По подразбиране TSC не се активира, тъй като в миналото този източник не изключваше постепенно натрупване на отклонения във времето, което в други обработвачи се коригираше софтуерно за постигане на по-точни показания. Според инженера, специализирал се в разработката на процесори, опасенията относно времевите отклонения при използване на TSC отдавна не съответстват на действителността и в съвременни процесори този източник може години наред да предоставя стабилни показания.
Работен превод сървъри в Netflix с източник TSC доведе до намаляване на забавянията при запис с 43 % и постигане на резултати в Ubuntu, които превишават четирикратно конфигурацията с CentOS, използваща времевия източник "xen". Резултатите от проведеното изследване бяха предадени на компанията Amazon, която официално препоръча в среди AWS EC2 на базата на хипервизор Xen да се използва по подразбиране времевият източник TSC (в среди, основани на хипервизор Nitro, остава препоръчаният kvm-clock).
Източник: opennet.ru
