Специалист по низкоуровневой оптимизации приложений, Саша Гольдштейн, в рамках своего доклада на JPoint немного отклонится от привычной тематики .NET и расскажет об инструментарии, помогающем бороться за производительность Java приложений под Linux. Что это за инструмент, кому он нужен и зачем, мы решили узнать заранее и взяли у Саши интервью.
JUG.Ru Group: Расскажите, пожалуйста, пару слов о себе и своей работе?
Саша Гольдштейн: Меня зовут Саша Гольдштейн, последние 10 лет я работаю в израильской консалтинговой компании Sela в качестве CTO.
Моя работа сфокусирована на вопросах оптимизации производительности, диагностике на продакшн, мониторинге и всевозможных низкоуровневых задачах.
Моя типичная рабочая неделя наполнена самыми разными задачами: я преподаю, исправляю ошибки или проблемы производительности для клиентов, а также работаю над внутренними проектами. Также я вхожу в программный комитет пары конференций: нашей собственной SDP (Тель-Авив, Израиль), а также DotNext (Москва и Санкт-Петербург, Россия), что на удивление занимает довольно много времени.
«Производительность большинства приложений определяется не железом или средой исполнения» – Sasha Goldshtein о мониторинге производительности Java под Linux
JUG.Ru Group: Обычно вы много рассказываете о производительности .NET. Что подтолкнуло вас в сторону Java?
Саша Гольдштейн: Действительно, большая часть моей работы связана с C# и C++ под Windows. Я провел много времени, оптимизируя и решая выявленные проблемы с производительностью .NET. Однако в работе над низкоуровневой оптимизацией и отладкой в рамках разных технологий прослеживаются общие элементы: инструменты могут иметь разные названия, но общие принципы, методология и мыслительный процесс совпадают. В последние пару лет я близко познакомился с BPF — фреймворком трассировки под Linux, и это подтолкнуло меня к идее использования BPF для анализа производительности JVM.
JUG.Ru Group: В чем особенности борьбы за производительность в Java на фоне .NET?
Саша Гольдштейн: Как я сказал, многие вещи идентичны. Производительность большинства приложений определяется не железом или средой исполнения (JVM, CLR, Python или чем-то еще), а окружением: особенностями доступа к базам данных, скоростью поиска на диске и обработки сетевых запросов. Для подобного класса приложений по большому счету не важно, какую среду исполнения вы используете. Когда речь заходит о низкоуровневой оптимизации, например, минимизации потребления памяти, оптимизации отдельных алгоритмов, скорость работы которых определяется процессором (CPU-bound), и тому подобных вещах, есть ситуации, в которых разница между платформами действительно имеет значение, особенно если вам необходимо настроить среду исполнения под ваше приложение. В общем случае JVM настраивается более гибко, нежели CLR; и, мне кажется, в последние годы больше усилий было вложено именно в оптимизацию различных реализаций JVM, чем в Microsoft CLR.
JUG.Ru Group: В каких случаях борьба за производительность реально требуется, все-таки эта задача «дорогая» в плане временных затрат? Какие факторы явно говорят о том, что с перфомансом есть проблемы?
Саша Гольдштейн: Зачастую производительность не является функциональным показателем, которого необходимо достичь. Но даже если вы не строите системы реального времени или сверхбыстрые клиентские приложения, есть, вероятно, некоторые минимальные (разумные) границы скорости, которые ваши пользователи не будут готовы пересечь. Например, веб API, которому требуется 5 секунд на обработку запроса на входа в систему, скорее всего разозлит людей. Есть еще и вопрос стоимости: оптимизация производительности обычно означает, что вам потребуется меньше аппаратных ресурсов, а это означает прямую непосредственную экономию затрат, учитывая принятую многими политику «облака в первую очередь» (cloud-first).
Остается надеяться, что у большинства людей предусмотрен процесс для определения целевых показателей производительности и по крайней мере простейший способ мониторинга и проверки этих показателей по мере продвижения вперед процесса разработки.
JUG.Ru Group: С чего стоит начинать исследование проблем с производительностью?
Саша Гольдштейн: Критичным моментом является наличие хорошего описания системы, например, функциональной блок-схемы. Когда вы понимаете, условно говоря, «механику работы»: какие есть основные компоненты и как они между собой связаны, гораздо проще предположить, где искать узкие места, также как гораздо легче понять, с чего стоит начинать поиск проблемы. Инструменты — вторичны. Прежде чем запустить ворох инструментов, вам необходимо понять, какие есть различные ресурсы, как они могут перегружаться, и как проверить предложенные гипотезы, чтобы добиться прогресса. Например, вы можете потратить дни на оптимизацию производительности CPU при выполнении некоторого алгоритма сортировки, но после этого обнаружите, что 99% времени отнимает запрос данных из БД, так что более или менее эффективная сортировка не дает вклада в общее время выполнения.
JUG.Ru Group: Можете ли вы рассказать об основных возможностях инструментария на примере BPF?
Саша Гольдштейн: BPF представляет собой мощный механизм ядра, представленный в последних версиях ядер Linux и позволяющий вводить динамические программы трассировки в ядро. Эти программы контролируемо безопасны и не могут привести к сбою в системе, также они не требуют компиляции и загрузки модулей ядра. В результате у нас есть фреймворк трассировки, который может работать очень близко к источнику основных событий, в частности, к обработке сетевых пакетов, отправке запросов к диску, обработке аппаратных прерываний и аналогичных. Предвидя ваш вопрос отмечу, что есть также некоторые специфичные для JVM события, которые я буду рассматривать в рамках доклада на JPoint: сборка мусора, распределение объектов, блокировка на освобождение монитора и многие другие.
Более того, BPF позволяет создавать инструменты, в которых агрегация происходит на уровне трассировщика — например, если вас беспокоит гистограмма задержек (например, задержек HTTP-запросов), вам не нужно делать дамп миллиона событий, а затем проводить постобработку для вычисления гистограммы. Вместо этого ваша BPF-программа обеспечивает агрегирование в режиме реального времени и выдает на анализ только окончательный результат.
Существует очень мощный инструментарий, который разрабатывается людьми из Facebook, Netflix, Plumgrid (VMWare) и других компаний (в том числе при моем скромном участии :-)).
JUG.Ru Group: Насколько он сложен во внедрении в рабочий процесс и освоении?
Саша Гольдштейн: BPF не сложен в использовании, поскольку есть множество вызываемых всего одной командной строкой инструментов, которые могут быть использованы для выявления проблем с производительностью. Например, есть инструмент под названием mysqld_slower, который выводит медленные запросы MySQL.
Единственная проблема заключается в том, что вам нужно установить новое ядро Linux, чтобы использовать инструменты BPF. Большая часть функциональности была включена в Linux 4.1 и 4.4 (который у вас есть в Ubuntu 16.04, например), но другие функции требуют еще более новых версий, в частности, 4.9, которых у большинства пока нет в продакшене. Это конечно можно обойти путем обновления только ядра, благодаря такому подходу компании, вроде Facebook, Netflix и других, получили все преимущества BPF.
JUG.Ru Group: Можно ли привести пример «типичных граблей» в работе с performance, с которыми позволяет бороться инструментарий на основе BPF?
Саша Гольдштейн: Инструменты BPF полезны для диагностики приложений, ограниченных возможностями процессора, временем блокировки (блокировки, I/O), проблемами доступа к файлам, медленными запросами к базам данных, сетевыми запросами, сборкой мусора — на самом деле очень широким спектром проблем. Многие из них я рассмотрю в своем докладе.
JUG.Ru Group: Есть ли задачи, с которыми позволяет разобраться только этот инструментарий?
Саша Гольдштейн: Да. Когда вам нужно обработать трассировщиком большое количество событий, BPF незаменим. Даже довольно простые сценарии, такие как профилирование CPU, можно сделать намного более эффективным при использовании поддержки профилирования в BPF. В большинстве случаев решение задач, вроде обработки каждого входящего запроса и агрегирования информации о задержке, не практично с другими инструментами анализа производительности.
В моем докладе мы рассмотрим мониторинг блокировок, разрешение DNS, запросы MySQL и кучу других проблем, которые можно назвать типичными для систем на продакшене.
JUG.Ru Group: Ваш доклад — больше практический. На кого он в первую очередь ориентирован?
Саша Гольдштейн: Мой доклад предназначен для разработчиков и инженеров по эксплуатации (Ops Engineer), развивающих ПО под Linux. Фокус внимания будет направлен на JVM (потому что это JPoint!), так что все примеры будут на Java. Мы рассмотрим кучу примеров, которые, я надеюсь, будут полезны для диагностики проблем с их собственными системами — и даже если у вас нет достаточно свежей версии ядра Linux сегодня, оно появится в самом ближайшем будущем. Я думаю, каждый разработчик, работающий на Linux, в один прекрасный день найдет применение для инструментов BPF.
Если у вас есть вопросы, предложения и замечания — спрашивайте, Саша готов ответить на них в комментариях.
P.S. Кроме Саши, на JPoint 2017 о перфомансе будут рассказывать Алексей @shipilev Шипилёв, Сергей Walrus Куксенко, Владимир vladimirsitnikov Ситников и Николай xpinjection Алименков. О чем именно? Смотрите список докладов.
А если вы живете в Сибири и до Москвы вам не добраться, рекомендуем присмотреться к JBreak 2017.
Автор: JUG.ru Group
