Брендан Грег (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