Пример анализе перформанси

Да бисте пратили видео упутства, отворите пример извештаја овде.

Како тумачити извештај о перформансама

Користећи HQbird, или као посебну услугу, IBSurgeon Performance Analysis са cc.ib-aid.com, можете генерисати извештај о перформансама из Firebird trace логова.

Овај извештај је моћан дијагностички алат који пружа детаљне информације о извршавању SQL упита у Firebird базама података. Овај водич објашњава како тумачити и користити trace извештаје за систематско идентификовање и решавање уских грла у перформансама.

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-у, а скраћена верзија је доступна на Portal алату - погледајте овај видео за детаље).

• Помаже у идентификовању образаца и аномалија: поређење графика из периода са добрим перформансама (нпр. прошле недеље/месеца) са периодима са проблемима у перформансама може помоћи у идентификовању проблема.

2. Анализа најбољих упита

• Више перспектива рангирања за свеобухватну анализу: најдужи упити, најчешћи упити, најзахтевнији упити (груписани по тексту или плану), и више.

• Свака димензија открива различите могућности за оптимизацију

• Детаљна статистика за сваки упит укључујући:

• Метрике трајања (мин, макс, просек, медијана)

• Потрошња ресурса (fetches, reads, writes)

• Обрасци извршавања - број извора за најбоље упите.

3. Резиме процеса

• Групише статистику по процесу извршавања

• Помаже у идентификовању проблематичних апликација

• Приказује потрошњу ресурса и операције над базом података (конекције, упити, итд.) и метрике (fetches, reads, итд.) по процесу

4. Резиме адреса

• Групише статистику по клијентској конекцији

• Открива расподелу оптерећења међу клијентима

• Помаже у идентификовању проблема специфичних за конекцију

Свака секција подржава анализу перформанси на различитим нивоима:

• Обрасци на нивоу система (Графикони) - видите када и где се проблеми генерално јављају.

• Најуочљивији утицај упита (Top Queries) - идентификујте упите које треба прво оптимизовати.

• Проблеми на нивоу апликације (Process Summary) - идентификујте апликације које стварају проблеме у перформансама.

• Проблеми на нивоу клијента (Address Summary) - идентификујте IP адресе (радне станице, клијентске рачунаре) са највећим протоком упита.

2. Анализа временског резимеа и резимеа плана

Препоручује се да анализу ситуације са перформансама започнете са Summary секцијама. Кликните овде да отворите Plan-Summary секцију у примеру извештаја.

Временски резиме агрегира укупно време извршавања за сваки јединствени образац SQL изјаве.

Мислите о томе као о извештају “центра трошкова” који показује који упити троше највише ресурса базе података током времена.

Ако упити нису параметризовани, тј. експлицитно садрже вредности параметара унутар SQL текста уместо placeholder-а за параметре (:myparam1), неопходно је користити секцију "Plan-Summary" да бисте идентификовали упите са највећом учесталошћу.

Пример непараметризованного запроса: 'SELECT * FROM COUNTRY WHERE COUNTRYID=2'
Пример параметризованного запроса: 'SELECT * FROM COUNTRY WHERE COUNTRYID=:paramid'

Каждый запрос в разделе Summary имеет заголовок со следующими ключевыми частями:

• Summary: Процент от общего времени, показывает, какую долю общего времени базы данных потребляет запрос.

• Frequency: Сколько раз встречается шаблон запроса

• Fetch, Read, Write: метрики ресурсов

Например, если есть

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% случаев этого достаточно для воспроизведения проблемы).

Ниже у нас есть отдельный график с выполнениями этого конкретного запроса. Как вы видите, этот запрос был запущен в период высокой нагрузки, которую мы заметили на обзорном графике.

И в конце у нас есть очень важная коллекция статистики для ВСЕХ запросов, соответствующих шаблону, а также список адресов источников:

В этой статистике мы видим минимальное, максимальное, среднее и медианное время выполнения, а также аналогичную статистику для выборок (fetches), чтений (reads), записей (writes) и отметок (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 ms) указује на доследне перформансе

• Однос макс/мин (~11x) указује на извесну варијабилност

• 20,29% укупног времена је значајно - да ли је овај упит у топ 3 у секцији Фреквенција или План-фреквенција? (да, јесте.)

4.4. Метрике коришћења ресурса

4.4.1. Операције преузимања

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

Преузимања представљају добијање редова:

• Доследни бројеви преузимања (разлика мин/макс од само 33) указују на стабилне скупове резултата

• Релативно високи бројеви преузимања (>7000 по извршењу) могу указивати на:

• Потребу за ограничавањем скупа резултата и/или пагинацијом, ако се враћа много записа.

• Потенцијал за оптимизацију упита - посебно има смисла ако је упит у топ 3 у секцији Фреквенција/План-фреквенција.

4.5. Операције читања

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

Физичка читања указују на приступ диску:

• Нулта медијана са ненултим максимумом сугерише повремене промашаје кеша

• 8,22% укупних читања указује на умерени I/O утицај

• Велики јаз између мин (0) и макс (6995) сугерише променљиву ефикасност кеша.

4.6. Операције уписа

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

Ако упит не врши уписа, обично је реч о операцији само за читање.

4.7. Операције означавања

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 локални хост)

• Свих 4428 извршења са истог извора

4.9. Коришћење ових метрика за оптимизацију

4.9.1. Анализа образаца перформанси

Доследност извршења

• Упоредите мин/макс трајања

• Потражите одступања у коришћењу ресурса

• Проверите медијану наспрам просека за варијабилност

Обрасци коришћења ресурса

• Висока преузимања → Прегледајте величину скупа резултата

• Висока читања → Проверите покривеност индекса

• Висока означавања → Испитајте контенцију закључавања

Анализа утицаја клијента

• Више клијената → Величина базена конекција

• Појединачна клијент → Оптимизација апликације

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

На основу ових метрика, приоритизујте:

• Величина скупа резултата

• 7000 преузимања по извршењу

• Размотрите додавање LIMIT/OFFSET

• Прегледајте листу колона у SELECT-у

Стратегија кеширања

• Често извршење (4428 пута)

• Доследна величина резултата

• Без укључених уписа

Вероватно, овај упит може да се извршава ређе.

Коришћење индекса

• Променљиви бројеви читања

• Нулта медијана читања, али висок максимум

• Прегледајте покривеност индекса

5. Практична примена

За овај конкретни пример:

Краткорочна побољшања:

• Имплементирајте кеширање резултата (висок број извршења, доследна преузимања)

• Прегледајте величину скупа резултата (>7000 преузимања по извршењу)

Средњорочна оптимизација:

• Анализирајте обрасце коришћења индекса

• Размотрите коришћење припремљених изјава

• Прегледајте логику апликације за учесталост извршења

Дугорочна разматрања:

• Пратите обрасце извршења током времена

• Планирајте стратегију одржавања индекса

• Размотрите промене у обрасцима приступа подацима

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].