Анализ влияния на производительность выбранного в системе источника времени
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Брендан Грег (Brendan Gregg), один из разработчиков DTrace, ныне развивающий средства для анализа производительности на базе BPF в ядре Linux, обобщил опыт, полученный в ходе разбора проблем с производительностью, с которыми компания Netflix столкнулась при переводе СУБД Cassandra c 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 раз медленнее. На языке Си была написана похожая программа, сто миллионов раз вызывающая функцию gettimeofday(), но при её выполнения были получены аналогичные результаты.
Так как стало ясно, что источником проблемы является функция возврата текущего времени внимание переключилось на изменение показателей при выборе в системе разных источников точного времени. Судя по содержимому "/sys/devices/system/clocksource/clocksource0/current_clocksource" по умолчанию при запуске Linux в гостевой системе использовался таймер "xen". После изменения источника времени на "tsc" тестовое приложение стало выполняться быстрее в 20 раз.
$ 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 (Time Stamp Counter) производительность одинаково возросла в CentOS и Ubuntu, но относительно CentOS запуск в Ubuntu по-прежнему остался в 5 раз медленнее (0.13 против 0.68 мкс), хотя задержки теперь стали слишком малы, чтобы оказывать заметное влияние на производительность. Дополнительно был проведён тест производительности источника времени kvm-clock, который показал увеличение задержек на 20%, по сравнению с TSC.
Для получения времени при выборе источника TSC используется процессорная инструкция RDTSC, выполнение которой не требует совершение системного вызова (инструкция не требует повышенных привилегий и выдаёт значение из встроенного в CPU счётчика времени). По умолчанию TSC не активируется так как в былые времена данный источник не исключал постепенный дрейф времени, который в других обработчиках корректируется программно для достижения более точных показаний. По мнению инженера, специализирующегося на разработке процессоров, опасения о сдвигах времени при использовании TSC уже давно не соответствуют действительности и в современных процессорах данный источник может годы выдавать стабильные показания.
Перевод рабочих серверов в Netflix на источник TSC привёл к снижению задержек при записи на 43% и достижению при использовании Ubuntu результатов, превосходящих конфигурации с CentOS с источником времени "xen". Результаты проведённого исследования были переданы компании Amazon, которая официально рекомендовала в окружениях AWS EC2 на базе гипервизора Xen использовать по умолчанию источник времени TSC (в окружениях на базе гипервизора Nitro остаётся рекомендован kvm-clock).
===========
Источник:
OpenNet.RU
===========
Похожие новости
- Главная ссылка к новости (http://www.brendangregg.com/bl...)
- OpenNews: Для Linux представлена система динамической отладки BPFtrace (DTrace 2.0)
- OpenNews:
Сравнение производительности сетевого драйвера в вариантах на 10 языках программирования
- OpenNews: Эксперимент по настройке Linux для блокирования 10 млн пакетов в секунду
- OpenNews: Оптимизация Linux для обработки 1.2 млн JSON-запросов в секунду
- OpenNews: Компания Cloudflare подготовила патчи, кардинально ускоряющие дисковое шифрование в Linux
Похожие новости:
- Выпуск дистрибутива Альт Рабочая станция К 9.2
- Проект Waydroid развивает пакет для запуска Android в дистрибутивах GNU/Linux
- Релиз дистрибутива для исследования безопасности Kali Linux 2021.3
- 30 лет с момента первого релиза ядра Linux 0.01
- Осеннее обновление стартовых наборов ALT p10
- Компания Microsoft опубликовала обновление Linux-дистрибутива CBL-Mariner
- Драйвер NTFS от Paragon Software принят в состав ядра Linux 5.15
- Доступен полностью свободный вариант ядра Linux-libre 5.14
- Для ядра Linux предложена реализация SMB-сервера
- Релиз ядра Linux 5.14
Теги для поиска: #_linux, #_time, #_speed, #_tune, #_optimization
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 00:58
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Брендан Грег (Brendan Gregg), один из разработчиков DTrace, ныне развивающий средства для анализа производительности на базе BPF в ядре Linux, обобщил опыт, полученный в ходе разбора проблем с производительностью, с которыми компания Netflix столкнулась при переводе СУБД Cassandra c 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 раз медленнее. На языке Си была написана похожая программа, сто миллионов раз вызывающая функцию gettimeofday(), но при её выполнения были получены аналогичные результаты. Так как стало ясно, что источником проблемы является функция возврата текущего времени внимание переключилось на изменение показателей при выборе в системе разных источников точного времени. Судя по содержимому "/sys/devices/system/clocksource/clocksource0/current_clocksource" по умолчанию при запуске Linux в гостевой системе использовался таймер "xen". После изменения источника времени на "tsc" тестовое приложение стало выполняться быстрее в 20 раз. $ 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 =========== Похожие новости
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 00:58
Часовой пояс: UTC + 5