Приклад аналізу продуктивності

Щоб переглянути відеоінструкцію, відкрийте приклад звіту тут.

Як інтерпретувати звіт про продуктивність

Використовуючи HQbird або, як окрему послугу, IBSurgeon Performance Analysis з cc.ib-aid.com, ви можете створити звіт про продуктивність на основі журналів трасування Firebird.

Цей звіт є потужним діагностичним інструментом, який надає детальну інформацію про виконання SQL-запитів у базах даних Firebird. Цей посібник пояснює, як інтерпретувати та використовувати звіти трасування для систематичного виявлення та усунення проблем із продуктивністю.

1. Структура звіту про продуктивність

┌─────────────────────────────────────────┐
│         Performance Report              │
├─────────────────────────────────────────┤
│ 1. Performance Summary Graphs           │
│    ┌────────────────────────┐           │
│    │  Top queries	      │           │
│    │     Top summary	      │           │
│    │     Top frequency      │           │
│    │     Durations          │           │
│    │     Fetches  	      │           │
│    │     Reads	      │           │
│    │     Writes	      │           │
│    │  Time Series Chart     │           │
│    │     Durations          │           │
│    │     Count of queries   │           │
│    │     Fetches            │           │
│    │     Reads/Writes       │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 2. Top Queries Analysis                 │
│    ┌────────────────────────┐           │
│    │ Query Rankings         │           │
│    │                        │           │
│    │  By Duration───┐       │           │
│    │                │       │           │
│    │  By Time   ────┤       │           │
│    │  Summary       │       │           │
│    │                │       │           │
│    │  By Plan   ────┤       │           │
│    │  Summary       │       │           │
│    │                │       │           │
│    │  By Frequency ─┤       │           │
│    │                │       │           │
│    │  By Plan    ───┤       │           │
│    │  Frequency     │       │           │
│    │                │       │           │
│    │  By Fetches ───┤       │           │
│    │                │       │           │
│    │  By Reads   ───┤       │           │
│    │                │       │           │
│    │  By Writes  ───┘       │           │
│    │                        │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 3. Process Summary                      │
│    ┌────────────────────────┐           │
│    │ Per Process Stats      │           │
│    │ - Execution counts     │           │
│    │ - Fetches, etc	      │           │
│    │ - Duration metrics     │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 4. Address Summary                      │
│    ┌────────────────────────┐           │
│    │Per Client Address Stats│           │
│    │ - Connection counts    │           │
│    │ - Durations  	      │           │
│    │ - Fetches,etc          │    	  │
│    │ - Process names        │ 	  │
│    └────────────────────────┘           │
└─────────────────────────────────────────┘

Структура деталей запиту:
┌────────────────────┐
│ Query Information  │
├────────────────────┤
│ - SQL Text         │
│ - Transaction info │
│ - Execution Plan   │
│ - Duration Stats   │
│ - Resource Stats   │
│   * Fetches        │
│   * Reads          │
│   * Writes         │
│   * Marks          │
│ - Client Info      │
└────────────────────┘

Звіт про продуктивність надає ієрархічне представлення активності бази даних:

1. Графіки зведення продуктивності

• Візуальне представлення ключових показників у часі - ви легко можете побачити піки активності/навантаження. (Також доступний звіт із помінутним аналізом у Advanced Performance Monitoring в HQbird, скорочена версія якого доступна на порталі - дивіться це відео для деталей).

• Допомагає виявити закономірності та аномалії: порівняння графіків із періодів хорошої продуктивності (наприклад, минулого тижня/місяця) із періодами проблем із продуктивністю може допомогти виявити проблему.

2. Аналіз найкращих запитів

• Кілька перспектив ранжування для комплексного аналізу: найдовші запити, найчастіші запити, найбільш ресурсомісткі запити (згруповані за текстом або планом) тощо.

• Кожен вимір відкриває різні можливості для оптимізації

• Детальна статистика для кожного запиту, включаючи:

• Показники тривалості (мін, макс, середнє, медіана)

• Споживання ресурсів (fetches, reads, writes)

• Патерни виконання - кількість джерел для найкращих запитів.

3. Зведення процесів

• Групує статистику за виконуваним процесом

• Допомагає виявити проблемні застосунки

• Показує споживання ресурсів та операції з базою даних (з’єднання, запити тощо) та показники (fetches, reads тощо) для кожного процесу

4. Зведення адрес

• Групує статистику за клієнтським з’єднанням

• Розкриває розподіл навантаження між клієнтами

• Допомагає виявити проблеми, пов’язані з конкретними з’єднаннями

Кожен розділ підтримує аналіз продуктивності на різних рівнях:

• Системні закономірності (Графіки) - побачте, коли і де виникають проблеми загалом.

• Найпомітніший вплив від запитів (Top Queries) - визначте запити, які слід оптимізувати в першу чергу.

• Проблеми на рівні застосунків (Зведення процесів) - визначте застосунки, які створюють проблеми з продуктивністю.

• Проблеми на рівні клієнтів (Зведення адрес) - визначте IP-адреси (робочі станції, комп’ютери клієнтів) із найбільшим потоком запитів.

2. Аналіз Time Summary та Plan-Summary

Рекомендується розпочинати аналіз ситуації з продуктивністю з розділів Summary. Натисніть тут, щоб відкрити розділ Plan-Summary у прикладі звіту.

Time Summary агрегує загальний час виконання для кожного унікального шаблону SQL-оператора.

Сприймайте це як звіт про “центри витрат”, який показує, які запити споживають найбільше ресурсів бази даних протягом часу.

Якщо запити не параметризовані, тобто явно містять значення параметрів у тексті SQL замість заповнювачів параметрів (:myparam1), необхідно використовувати розділ "Plan-Summary" для визначення запитів із найвищою частотою.

Приклад непараметризованого запиту: ‘SELECT * FROM COUNTRY WHERE COUNTRYID=2’ Приклад параметризованого запиту: ‘SELECT * FROM COUNTRY WHERE COUNTRYID=:paramid’

Кожен запит у розділі Summary має заголовок з наступними ключовими частинами:

![](/download/trace/example_3_header.png)

- **Summary**: Відсоток загального часу, показує, яку частку загального часу роботи бази даних споживає запит.

- **Frequency**: Скільки разів зустрічається шаблон запиту.

- **Fetch, Read, Write**: Показники ресурсів.

Наприклад, якщо є

```none hljs
Summary: 19.08% (3920272 of 20541791 ms)

Це говорить нам про те, що цей шаблон запиту споживає майже 20% загального часу роботи бази даних - значна частка, яка потребує негайної уваги.

Нижче заголовка в розділі Plan-Summary ми побачимо план виконання SQL, який використовувався для групування запитів, а в Time-Summary - текст самого запиту.

Оскільки шаблон запиту представляє більш ніж один конкретний запит, інформація про з’єднання береться з першого запиту, який відповідає шаблону:

На скріншоті вище ви можете бачити заголовок прикладу оператора для шаблону, він складається з назви застосунку, який запустив цей SQL, ID з’єднання та ID транзакції, а також IP-адреси та деталей транзакції.

Нижче йде план (для Time-Summary, для Plan-Summary він пропускається, оскільки вже показаний на початку), значення параметрів (у порядку появи) та статистика по таблицях:

Будь ласка, пам’ятайте: у Plan-Summary ми групуємо SQL за планом виконання, це означає, що лише план є постійним для шаблону, а для Time-Summary ми групуємо за текстом SQL-оператора, і інші речі (значення параметрів, час виконання тощо) можуть відрізнятися. Використовуйте цю інформацію як приклад шаблону виконання (у 99% випадків цього достатньо для відтворення проблеми).

Нижче ми маємо окремий графік із виконаннями цього конкретного запиту. Як ви можете бачити, цей запит був запущений у період високого навантаження, яке ми помітили на загальному графіку.

І, нарешті, ми маємо дуже важливу колекцію статистики для ВСІХ запитів, які відповідають шаблону, а також список адрес джерел:

У цій статистиці ми можемо бачити мінімальний, максимальний, середній та медіанний час виконання, а також аналогічну статистику для fetch, read, write та marks (операції скидання кешу).

2.1. Як використовувати Time Summary:

• Спочатку визначте запити, які споживають непропорційно багато часу (вони є топ-3 цього розділу - #1, 2, 3)

• Порівняйте споживання часу з частотою

• Подивіться на середній час виконання (загальний час / частота) у нижній частині розділу запиту (див. нижче)

• Шукайте закономірності, де:

• Високий час + низька частота = неефективні окремі запити

• Високий час + висока частота = потенційно неефективні, але інтенсивно використовувані запити

3. Аналіз частоти: Frequency та Plan-Frequency

Використовуйте аналіз частоти, щоб зрозуміти, як часто виконуються запити. Уявіть це як підрахунок того, скільки разів певна дорога використовується в годину пік.

Якщо запити не параметризовані, тобто явно містять значення параметрів у тексті SQL замість плейсхолдера параметра (:myparam1), необхідно використовувати розділ "Plan-Summary" для визначення запитів із найвищою частотою.
Приклад непараметризованого запиту: 'SELECT * FROM COUNTRY WHERE COUNTRYID=2'
Приклад параметризованого запиту: 'SELECT * FROM COUNTRY WHERE COUNTRYID=:paramid'

3.1. Розуміння впливу частоти

Представлення шаблону Frequency дуже схоже на Plan/Time Summary:

Високочастотні запити схожі на завантажені перехрестя - навіть якщо кожен автомобіль (запит) рухається швидко, великий обсяг може спричинити затори. Це впливає на:

• З’єднання з базою даних (як паркувальні місця - обмежена кількість)

• Пропускну здатність мережі (як пропускна здатність дороги)

• Використання CPU (як диспетчери руху, які перевантажуються)

• Ефективність кешу (як необхідність повторно звертатися до однієї й тієї ж інформації)

Щоб оцінити вплив високочастотних запитів, зберіть трасування з порогом параметра = 0.

3.2. Категорії впливу частоти

3.3. Приклад аналізу

Розглянемо реальний випадок із нашого звіту трасування:

Frequency: 4,428 executions (24.43% of total)
Impact: Critical - high volume of SALES table queries
Root Cause: Repetitive customer balance checks
Optimization Priority: High

Explanation: This query is running thousands of times, similar to a
busy intersection. Even though each execution might be quick, the
cumulative impact is significant. The application might be checking
balances more often than necessary.

4. Аналіз статистики топових запитів у розділах xx-Summary та Frequency

Під час аналізу звітів трасування Firebird кожне групування запитів містить детальну агреговану статистику, яка надає важливу інформацію про закономірності продуктивності. Розглянемо кожен показник і зрозуміємо його значення для оптимізації бази даних.

4.1. Аналіз агрегованої статистики

Розглянемо цей приклад набору статистики:

Total: 4428 items:
Durations: min: 351; max: 3919; avg: 457.70; median: 455.00; sum: 2026710 (20.29%);
Fetches: min: 7135; max: 7168; avg: 7146.86; median: 7147.00; sum: 31646289 (0.75%);
Writes: min: 0; max: 0; avg: 0.00; median: 0.00; sum: 0 (0.00%);
Reads: min: 0; max: 6995; avg: 3.13; median: 0.00; sum: 13856 (8.22%);
Marks: min: 0; max: 0; avg: 0.00; median: 0.00; sum: 0 (0.00%);
From 1 unique addresses: TCPv6:::1 (4428)

4.2. Аналіз кількості виконань

4.2.1. Загальна кількість елементів

Total: 4428 items

Це число представляє кількість разів, коли цей конкретний шаблон запиту був виконаний протягом періоду трасування.

Розуміння цього числа допомагає вам:

• Розрахувати використання ресурсів на одне виконання

• Визначити, чи може бути корисним кешування запитів (або просто виконувати їх рідше)

Висока кількість виконань може вказувати на можливості для:

• Використання підготовлених операторів (і параметризованих) - той самий запит із тією ж частотою, будучи параметризованим і підготовленим для повторного виконання, потребуватиме менше ресурсів

• Додавання кешування результатів - кешування отриманого значення для використання під час тривалої операції або навіть довше, протягом сесії користувача, може зменшити необхідність частого виконання запиту

• Пакетної обробки операцій - розгляньте можливість виконання запиту для повернення або обробки багатьох записів одночасно, це усуне накладні витрати на виконання запиту (підготовку, передачу по мережі тощо).

4.3. Показники тривалості

4.3.1. Приклад компонентів тривалості

Durations: min: 351; max: 3919; avg: 457.70; median: 455.00; sum: 2026710 (20.29%);

4.3.2. Аналіз тривалості

• Близькі медіана та середнє значення (457.70 проти 455.00 мс) свідчать про стабільну продуктивність

• Співвідношення max/min (~11x) вказує на певну варіативність

• 20.29% загального часу є значним - чи є цей запит у топ-3 за частотою або частотою планів? (так, є.)

4.4. Показники використання ресурсів

4.4.1. Операції вибірки (Fetch)

Fetches: min: 7135; max: 7168; avg: 7146.86; median: 7147.00; sum: 31646289 (0.75%);

Fetches представляють отримання рядків:

• Стабільна кількість вибірок (різниця min/max лише 33) свідчить про стабільні набори результатів

• Відносно висока кількість вибірок (>7000 за виконання) може вказувати на:

• Необхідність обмеження набору результатів та/або пагінації, якщо повертається багато записів.

• Потенціал для оптимізації запиту - особливо доцільно, якщо запит у топ-3 за частотою/частотою планів.

4.5. Операції читання

Reads: min: 0; max: 6995; avg: 3.13; median: 0.00; sum: 13856 (8.22%);

Фізичні читання вказують на доступ до диска:

• Нульова медіана з ненульовим максимумом свідчить про періодичні промахи кешу

• 8.22% загальних читань вказує на помірний вплив на I/O

• Великий розрив між min (0) та max (6995) свідчить про змінну ефективність кешу.

4.6. Операції запису

Writes: min: 0; max: 0; avg: 0.00; median: 0.00; sum: 0 (0.00%);

Якщо запит не виконує записів, зазвичай це операція лише для читання.

4.7. Операції позначення (Mark)

Marks: min: 0; max: 0; avg: 0.00; median: 0.00; sum: 0 (0.00%);

Операції позначення пов’язані з управлінням кешем сторінок даних:

• Нульові позначення вказують на те, що жодна сторінка даних не була позначена для скидання, що типово для простих SELECT-запитів

• Ненульові позначення - операції з кешем

4.8. Аналіз клієнтських підключень

From 1 unique addresses: TCPv6:::1 (4428)

Це показує розподіл джерел запитів:

• Єдина клієнтська адреса свідчить про специфічний для застосунку запит

• Локальне підключення (::1 - це IPv6 localhost)

• Усі 4428 виконань з одного джерела

4.9. Використання цих показників для оптимізації

4.9.1. Аналіз патернів продуктивності

Стабільність виконання

• Порівняйте мінімальну/максимальну тривалість

• Шукайте викиди у використанні ресурсів

• Перевіряйте медіану проти середнього значення для варіативності

Патерни використання ресурсів

• Висока кількість вибірок → Перегляньте розмір набору результатів

• Висока кількість читань → Перевірте покриття індексів

• Висока кількість позначень → Дослідіть конкуренцію за блокування

Аналіз впливу клієнтів

• Кілька клієнтів → Розмір пулу підключень

• Один клієнт → Оптимізація застосунку

4.9.2. Пріоритети оптимізації

На основі цих показників пріоритезуйте:

• Розмір набору результатів

• 7000 вибірок за виконання

• Розгляньте додавання LIMIT/OFFSET

• Перегляньте список колонок у SELECT

Стратегія кешування

• Часте виконання (4428 разів)

• Стабільний розмір результатів

• Відсутність записів

Ймовірно, цей запит можна виконувати рідше.

Використання індексів

• Змінна кількість читань

• Нульова медіана читань, але високий максимум

• Перегляньте покриття індексів

5. Практичне застосування

Для цього конкретного прикладу:

Короткострокові покращення:

• Впровадьте кешування результатів (висока частота виконання, стабільні вибірки)

• Перегляньте розмір набору результатів (>7000 вибірок за виконання)

Середньострокова оптимізація:

• Проаналізуйте патерни використання індексів

• Розгляньте використання підготовлених запитів (prepared statements)

• Перегляньте логіку застосунку щодо частоти виконання

Довгострокові міркування:

• Моніторте патерни виконання з часом

• Сплануйте стратегію обслуговування індексів

• Розгляньте зміни патернів доступу до даних

6. Аналіз тривалості

Аналіз тривалості досліджує, скільки часу займає виконання окремих запитів. Уявіть тривалість як секундомір, що засікає час кожного запиту - чим довше виконується запит, тим більша ймовірність проблем із продуктивністю.

6.1. Розуміння показників тривалості

Показники тривалості є критичними, оскільки вони безпосередньо впливають на досвід користувачів, тобто користувачі скаржаться, що “система повільна”. Подібно до того, як клієнти розчаровуються, стоячи в довгій черзі, користувачі розчаровуються, коли запити виконуються занадто довго. Довготривалі запити спричиняють:

• Поганий досвід користувача, коли екрани завантажуються занадто довго

• Ресурси системи зайняті протягом тривалого часу

• Інші запити чекають у черзі за повільними

• Потенційні проблеми з тайм-аутами в застосунках

6.2. Категорії впливу

6.3. Приклад аналізу

Duration: 77,793ms
Impact: Critical - single query consuming 77.7 seconds
Root Cause: Complex aggregation in PRC_COLLECT_RANKCATEGORY
Optimization Priority: Immediate

Explanation: This query is taking over a minute to execute, which is like
a complete traffic stoppage. The stored procedure is likely processing
too much data or using inefficient algorithms.

7. Стратегія впровадження

Думайте про оптимізацію як про покращення транспортної системи - потрібно виявити проблеми, спланувати рішення та впровадити зміни обережно.

7.1. Матриця пріоритетів

Ця матриця допомагає визначити, що потребує уваги в першу чергу, як сортування транспортних проблем у місті:

7.2. Покроковий процес оптимізації

1. Визначте критичні запити

• Шукайте найбільші затори (повільні запити)

• Знаходьте найзавантаженіші перехрестя (високочастотні запити)

• Виявляйте неефективні маршрути (високе використання ресурсів)

2. Проаналізуйте плани виконання

• Вивчіть поточні маршрути (використання індексів)

• Дослідіть патерни руху (методи з’єднань)

• Перевірте вузькі місця (операції сортування)

3. Впровадьте оптимізації

• Побудуйте нові дороги (індекси)

• Перепроектуйте маршрути (реструктуризація запитів)

• Додайте скорочення (кешування)

4. Перевірте покращення

• Виміряйте новий трафік (новий звіт трасування)

• Порівняйте показники до/після

• Задокументуйте, що спрацювало

Звертайтеся до IBSurgeon з будь-якими питаннями

Не соромтеся звертатися до нас з будь-якими питаннями: [email protected].