Подготовка к нагрузочному тестированию#

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

Если обязательные проверки не выполнены, результаты нагрузочного тестирования нельзя считать воспроизводимыми: при деградации будет невозможно отделить ограничения приложения от проблем инфраструктуры, мониторинга, СУБД или генератора нагрузки.

Обязательные проверки#

Требование	Что должно быть подтверждено	Документация
Внутренняя Grafana доступна и получает все штатные метрики.	Администратор может открыть Grafana, выбрать нужный временной диапазон, увидеть данные по pod’ам, JVM, сессиям, БД, NFS и системным компонентам.	Kubernetes: телеметрия кластера, Дашборды Grafana
Доступны метрики активных сессий.	На дашборде `System overview` отображается панель `Active sessions`; версия стенда мониторинга поддерживает эту панель.	Дашборд System overview, Kubernetes: метрики кластера,
Доступны метрики PostgreSQL, включая показатели записи.	В мониторинге видны состояние СУБД, активные подключения.	Пороги метрик: Сервер БД, pg_stat_kcache
Есть доступ к СУБД через DBeaver или другой SQL-клиент.	Учетная запись позволяет подключиться к целевой БД, выполнить диагностические запросы ниже и, по согласованию, сбросить статистику перед прогоном.	PgBouncer и DBeaver, Основные SQL-запросы для анализа
Работает Pyroscope.	В Grafana доступен раздел `Drilldown -> Profiles`, видны CPU/RAM-профили серверов приложений за период теста.	Диагностика нагрузки: дашборды, логи и Pyroscope
Есть права на выполнение JEXL из Global.	Тестовая учетная запись или сервисный пользователь может выполнять необходимые JEXL-скрипты через интерфейс или REST API `Btk_JexlGatePkg/execute`; выполнение разрешено только на согласованном тестовом контуре.	BASH-скрипт выполнения JEXL-кода через API системы
Работает статистика активных запросов и накопительная статистика SQL.	Доступны `pg_stat_activity` и один из вариантов накопительной статистики: `pg_stat_statements` для PostgreSQL или `pgpro_stats_statements` для Postgres Pro, если в поставке используется `pgpro_stats`.	Установка PostgreSQL: расширения, Основные SQL-запросы для анализа
Ресурсы кластера, pod’ов и СУБД соответствуют сайзингу.	CPU, RAM, диски, сетевые каналы, количество pod’ов, лимиты и requests не ниже значений, рассчитанных и согласованных для сценария теста.	Требования к нарезанию машин в кластере, Настройка групп ресурсов, Пороги метрик
NFS/S3-хранилище бизнес-объектов доступно и поставлено на мониторинг.	Global Server может читать и записывать в основное и дополнительные хранилища; в мониторинге видны доступность и заполнение NFS, а для S3 подтверждены доступность endpoint и права на bucket.	Добавление NFS-томов в Global Server, Настройка файлового хранилища по протоколу S3, Kubernetes: метрики кластера
Работает GlobalScheduler.	Планировщик запущен, выполняет тестовое задание, приватный ключ в контуре и публичный ключ в настройках Global согласованы.	Настройка GlobalScheduler, Метрики планировщика заданий
Работает QueueWalker, если он участвует в сценарии теста.	Обходчик очередей включен, имеет токен/секрет, корректный `exec_user`, доступ к URL выполнения JEXL и достаточно ресурсов для тестовой очереди.	Настройка книги ресурсов queuewalker, Конфигурация GlobalConfiguration
Сервер JMeter не является узким местом теста.	Генератор нагрузки имеет запас CPU/RAM/сети/диска, не использует swap, не размещен на узлах приложения или СУБД и во время пилотного прогона не достигает собственных лимитов.	Проверка сервера JMeter

Дополнительные проверки#

Требование	Что должно быть подтверждено	Документация
Настроены внешние метрики СУБД в Zabbix, Prometheus или VictoriaMetrics.	Помимо внутренней Grafana есть внешний контур мониторинга для долгосрочного хранения и анализа состояния СУБД за весь период теста.	Пороги метрик: Сервер БД
Управление кластером выполняется через `nscli`.	Установка, обновление комплекта приложения, переключение версий и служебные операции выполняются штатной утилитой, а не ручным изменением ресурсов без фиксации в конфигурации.	Скачайте nscli, Обновление системы с использованием nscli

Основные SQL-запросы для анализа#

Выполняйте запросы на тестовом контуре и только по согласованию с ответственным администратором БД. Запросы сброса статистики очищают накопленные счетчики, поэтому обычно их выполняют непосредственно перед началом прогона, чтобы получить чистый интервал измерений.

Проверка расширений#

select extname, extversion
from pg_extension
where extname in ('pg_stat_statements', 'pgpro_stats', 'pg_stat_kcache')
order by extname;

Сброс общей статистики PostgreSQL#

select pg_stat_reset();

PostgreSQL: pg_stat_statements#

select pg_stat_reset();

select a.wait_event, count(*)
from pg_stat_activity a
where a.state = 'active'
group by a.wait_event;

select a.query, count(*)
from pg_stat_activity a
where a.state = 'active'
group by a.query;

select pg_stat_statements_reset();

select t.total_exec_time, t.query, t.*
from pg_stat_statements t
order by t.total_exec_time desc;

Postgres Pro: pgpro_stats#

В поставках Postgres Pro вместо pg_stat_statements может использоваться расширение pgpro_stats. В этом случае основное представление называется pgpro_stats_statements, а сброс выполняется функцией pgpro_stats_statements_reset(). Описание расширения приведено в документации Postgres Pro: pgpro_stats. По умолчанию сброс статистики может выполнять суперпользователь; для сервисной учетной записи нужно выдать право отдельно.

select pgpro_stats_statements_reset();

select t.total_exec_time, t.query, t.*
from pgpro_stats_statements t
order by t.total_exec_time desc;

Проверка сервера JMeter#

Перед основным прогоном выполните короткий пилотный запуск с тем же профилем нагрузки и меньшей длительностью. Во время пилотного запуска проверьте сам сервер JMeter:

CPU не должен стабильно превышать 70-80%;
RAM должна иметь запас, swap должен быть выключен или не использоваться;
сетевой канал не должен упираться в лимит пропускной способности или packet loss;
диск должен выдерживать запись логов и результатов, если включено подробное логирование;
генератор нагрузки должен быть вынесен за пределы узлов приложения, СУБД и мониторинга.

Если сервер JMeter достигает собственных лимитов, результаты теста отражают ограничения генератора нагрузки, а не производительность тестируемого контура.

Подготовка к нагрузочному тестированию

Содержание