Пример анализа производительности

Для того чтобы следовать видеоинструкции, откройте пример отчёта здесь.

Как интерпретировать отчёт о производительности

Используя 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. Сводка по адресам

• Группирует статистику по клиентскому подключению

• Раскрывает распределение нагрузки между клиентами

• Помогает выявить проблемы, связанные с конкретными подключениями

Каждый раздел поддерживает анализ производительности на разных уровнях:

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

• Наиболее заметное влияние запросов (Топ-запросы) - определить запросы, которые следует оптимизировать в первую очередь.

• Проблемы на уровне приложений (Сводка по процессам) - определить приложения, создающие проблемы с производительностью.

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

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

Рекомендуется начинать анализ ситуации с производительностью с разделов сводок. Нажмите здесь, чтобы открыть раздел сводки по планам в примере отчёта.

Сводка по времени агрегирует общее время выполнения для каждого уникального шаблона SQL-оператора.

Думайте об этом как об отчёте «центров затрат», который показывает, какие запросы потребляют больше всего ресурсов базы данных с течением времени.

Если запросы не параметризованы, т.е. явно содержат значения параметров в тексте SQL вместо плейсхолдеров параметров (:myparam1), необходимо использовать раздел «Сводка по планам», чтобы определить запросы с наибольшей частотой.

Пример непараметризованного запроса: ‘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 из 20541791 мс)

Это говорит нам о том, что данный шаблон запроса потребляет почти 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 выполнений (24.43% от общего числа)
Impact: Критический - высокий объём запросов к таблице SALES
Root Cause: Повторяющиеся проверки баланса клиентов
Optimization Priority: Высокий

Explanation: Этот запрос выполняется тысячи раз, как оживлённый
перекрёсток. Даже если каждое выполнение может быть быстрым,
совокупное влияние значительно. Приложение может проверять балансы
чаще, чем необходимо.

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

При анализе отчётов трассировки Firebird каждая группа запросов содержит подробную агрегированную статистику, которая даёт важные сведения о закономерностях производительности. Давайте разберём каждую метрику и поймём её значение для оптимизации базы данных.

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

Рассмотрим этот пример набора статистики:

Total: 4428 элементов:
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%);
С 1 уникального адреса: TCPv6:::1 (4428)

4.2. Анализ количества выполнений

4.2.1. Общее количество элементов

Total: 4428 элементов

Это представляет собой количество раз, которое данный шаблон запроса был выполнен в течение периода трассировки.

Понимание этого числа помогает вам:

• Рассчитать использование ресурсов на одно выполнение.

• Определить, может ли быть полезным кэширование запросов (или просто выполнять их реже).

Высокое количество выполнений может указывать на возможности для:

• Использования подготовленных операторов (и параметризованных) - тот же запрос с той же частотой, будучи параметризованным и подготовленным для повторного выполнения, потребует меньше ресурсов.

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

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

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 мс) указывают на стабильную производительность

• Соотношение максимума к минимуму (~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%);

Выборки представляют собой извлечение строк:

• Стабильное количество выборок (разница между минимумом и максимумом всего 33) указывает на стабильные результирующие наборы

• Относительно высокое количество выборок (>7000 на выполнение) может указывать на:

• Необходимость ограничения результирующего набора и/или пагинации, если возвращается много записей.

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

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

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

Физические чтения указывают на обращение к диску:

• Нулевая медиана при ненулевом максимуме предполагает occasional промахи кэша

• 8.22% от общего количества чтений указывает на умеренное влияние операций ввода-вывода

• Большой разрыв между минимумом (0) и максимумом (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 выборок на выполнение)

Среднесрочная оптимизация:

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

• Рассмотрите использование подготовленных выражений

• Пересмотрите логику приложения для снижения частоты выполнения

Долгосрочные соображения:

• Отслеживайте паттерны выполнения с течением времени

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

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

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