У пошуках перформансу: моніторинг продуктивності JVM під Linux за допомогою BPF

Фахівець з низькорівневої оптимізації додатків, Саша Гольдштейн, в рамках своєї доповіді на 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.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.