# Подготовка к нагрузочному тестированию Раздел используется перед запуском нагрузочного тестирования на инфраструктуре заказчика. До начала прогона администратор заказчика должен подтвердить, что контур наблюдаем, доступен для диагностики, а выделенные ресурсы соответствуют согласованному сайзингу. Если обязательные проверки не выполнены, результаты нагрузочного тестирования нельзя считать воспроизводимыми: при деградации будет невозможно отделить ограничения приложения от проблем инфраструктуры, мониторинга, СУБД или генератора нагрузки. ## Обязательные проверки | Требование | Что должно быть подтверждено | Документация | |-----------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Внутренняя Grafana доступна и получает все штатные метрики. | Администратор может открыть Grafana, выбрать нужный временной диапазон, увидеть данные по pod'ам, JVM, сессиям, БД, NFS и системным компонентам. | [Kubernetes: телеметрия кластера](050_k8s_cluster_monitoring.md), [Дашборды Grafana](030_monitoring_reference.md) | | Доступны метрики активных сессий. | На дашборде `System overview` отображается панель `Active sessions`; версия стенда мониторинга поддерживает эту панель. | [Дашборд System overview](030_monitoring_reference.md#дашборд-system-overview), [Kubernetes: метрики кластера](055_k8s_cluster_metrics.md), | | Доступны метрики PostgreSQL, включая показатели записи. | В мониторинге видны состояние СУБД, активные подключения. | [Пороги метрик: Сервер БД](020_metrics_thresholds.md#6-сервер-бд-postgresql), [pg_stat_kcache](../020_install-postgres/080_pg_stat_kcache.md) | | Есть доступ к СУБД через DBeaver или другой SQL-клиент. | Учетная запись позволяет подключиться к целевой БД, выполнить диагностические запросы ниже и, по согласованию, сбросить статистику перед прогоном. | [PgBouncer и DBeaver](../020_install-postgres/020_pgbouncer.md), [Основные SQL-запросы для анализа](#основные-sql-запросы-для-анализа) | | Работает Pyroscope. | В Grafana доступен раздел `Drilldown -> Profiles`, видны CPU/RAM-профили серверов приложений за период теста. | [Диагностика нагрузки: дашборды, логи и Pyroscope](060_pyroscope_profiling.md) | | Есть права на выполнение JEXL из Global. | Тестовая учетная запись или сервисный пользователь может выполнять необходимые JEXL-скрипты через интерфейс или REST API `Btk_JexlGatePkg/execute`; выполнение разрешено только на согласованном тестовом контуре. | [BASH-скрипт выполнения JEXL-кода через API системы](../020_install-postgres/040_backup-restore.md#bash-скрипт-выполнения-jexl-кода-через-api-системы) | | Работает статистика активных запросов и накопительная статистика SQL. | Доступны `pg_stat_activity` и один из вариантов накопительной статистики: `pg_stat_statements` для PostgreSQL или `pgpro_stats_statements` для Postgres Pro, если в поставке используется `pgpro_stats`. | [Установка PostgreSQL: расширения](../020_install-postgres/010_install_postgres.md), [Основные SQL-запросы для анализа](#основные-sql-запросы-для-анализа) | | Ресурсы кластера, pod'ов и СУБД соответствуют сайзингу. | CPU, RAM, диски, сетевые каналы, количество pod'ов, лимиты и requests не ниже значений, рассчитанных и согласованных для сценария теста. | [Требования к нарезанию машин в кластере](../040_global-k8s/050_min_requirements.md), [Настройка групп ресурсов](../040_global-k8s/020_install.md#шаг-4-настройте-группы-ресурсов), [Пороги метрик](020_metrics_thresholds.md) | | NFS/S3-хранилище бизнес-объектов доступно и поставлено на мониторинг. | Global Server может читать и записывать в основное и дополнительные хранилища; в мониторинге видны доступность и заполнение NFS, а для S3 подтверждены доступность endpoint и права на bucket. | [Добавление NFS-томов в Global Server](../040_global-k8s/150_add_nfs_share.md), [Настройка файлового хранилища по протоколу S3](../040_global-k8s/150_add_nfs_share.md#настройка-файлового-хранилища-по-протоколу-s3), [Kubernetes: метрики кластера](055_k8s_cluster_metrics.md) | | Работает GlobalScheduler. | Планировщик запущен, выполняет тестовое задание, приватный ключ в контуре и публичный ключ в настройках Global согласованы. | [Настройка GlobalScheduler](../070_addition/020_scheduler_setup.md), [Метрики планировщика заданий](055_k8s_cluster_metrics.md#метрики-планировщика-заданий) | | Работает QueueWalker, если он участвует в сценарии теста. | Обходчик очередей включен, имеет токен/секрет, корректный `exec_user`, доступ к URL выполнения JEXL и достаточно ресурсов для тестовой очереди. | [Настройка книги ресурсов queuewalker](../040_global-k8s/020_install.md#шаг-4-настройте-группы-ресурсов), [Конфигурация GlobalConfiguration](../040_global-k8s/040_config.md) | | Сервер JMeter не является узким местом теста. | Генератор нагрузки имеет запас CPU/RAM/сети/диска, не использует swap, не размещен на узлах приложения или СУБД и во время пилотного прогона не достигает собственных лимитов. | [Проверка сервера JMeter](#проверка-сервера-jmeter) | ## Дополнительные проверки | Требование | Что должно быть подтверждено | Документация | |--------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Настроены внешние метрики СУБД в Zabbix, Prometheus или VictoriaMetrics. | Помимо внутренней Grafana есть внешний контур мониторинга для долгосрочного хранения и анализа состояния СУБД за весь период теста. | [Пороги метрик: Сервер БД](020_metrics_thresholds.md#6-сервер-бд-postgresql) | | Управление кластером выполняется через `nscli`. | Установка, обновление комплекта приложения, переключение версий и служебные операции выполняются штатной утилитой, а не ручным изменением ресурсов без фиксации в конфигурации. | [Скачайте nscli](../040_global-k8s/020_install.md#шаг-1-скачайте-nscli), [Обновление системы с использованием nscli](../040_global-k8s/070_upgrade.md#вариант-a-с-использованием-nscli) | ## Основные SQL-запросы для анализа Выполняйте запросы на тестовом контуре и только по согласованию с ответственным администратором БД. Запросы сброса статистики очищают накопленные счетчики, поэтому обычно их выполняют непосредственно перед началом прогона, чтобы получить чистый интервал измерений. ### Проверка расширений ```sql select extname, extversion from pg_extension where extname in ('pg_stat_statements', 'pgpro_stats', 'pg_stat_kcache') order by extname; ``` ### Сброс общей статистики PostgreSQL ```sql select pg_stat_reset(); ``` ### PostgreSQL: pg_stat_statements ```sql 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](https://postgrespro.ru/docs/postgrespro/current/pgpro-stats). По умолчанию сброс статистики может выполнять суперпользователь; для сервисной учетной записи нужно выдать право отдельно. ```sql 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 достигает собственных лимитов, результаты теста отражают ограничения генератора нагрузки, а не производительность тестируемого контура.