Общие принципы диагностики проблем с производительностью

В статье описаны основные подходы к диагностике проблем с производительностью.

Принципы диагностики, описанные в данной статье, затрагивают следующие темы:

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

Этапы диагностики

Подход к решению проблемы:

1. Собрать информацию об инфраструктуре: количество нод, использование балансировщика нагрузки, архитектура взаимодействия между компонентами.
2. Собрать логи приложения.
3. Собрать метрики серверов приложения, базы данных и сервера кэширования:

Таблица 1 — Метрики для сервера приложения

Таблица 2 — Метрики для сервера баз данных

Таблица 3 — Метрики для сервера кэширования

4. Собрать стандартные отчеты по базе данных приложения:
   • Для Microsoft SQL Server: sp_whoisactive и sp_blitzcache;
   • Для PostgreSQL: pg_stat_activity и pg_profile.

Отчет sp_whoisactive/pg_stat_activity показывает активные сессии и их блокировки. sp_blitzcache/pg_profile анализирует ресурсоемкие запросы. Также можно проверить индексы на фрагментацию, избыточность и отсутствие.

5. Сформировать HAR-файл на период воспроизведения проблемы.
6. Приступить к поиску решения проблемы.

Проблемы производительности могут быть связаны с нехваткой ресурсов на элементах инфраструктуры. После сбора информации проанализируйте достаточность серверных мощностей: попробуйте увеличить ресурсы временно на период диагностики или постоянно, либо снизить их потребление путем оптимизации.

Чтобы точнее оценить проблемы с производительностью, обратите внимание на следующие признаки:

1. Если процессор сервера приложения загружен на 90% и выше в течение 3–5 минут, это может указывать на нехватку CPU.
2. Для серверов баз данных, таких как Microsoft SQL Server или PostgreSQL, загрузка CPU на уровне 95% и выше в течение 10 минут и более допустима, но требует анализа. Это может быть следствием ресурсоемких запросов, признаком неэффективной индексации или нехватки ресурсов.
3. Если объем используемой оперативной памяти превышает 90% и активно используется файл подкачки (swap), скорее всего, не хватает RAM или есть утечки памяти.
4. Если задержка дисковых операций стабильно превышает 10-20 мс при нормальной нагрузке, это может указывать на узкое место в дисковой системе.
5. При проблемах с сетью обратите внимание на рост retransmit-ов, потери пакетов и увеличение задержек (RTT) между компонентами, особенно в распределенной инфраструктуре.

Если проблема связана с сервером базы данных:

1. Проанализировать отчет по тяжелым запросам в базе данных.
2. Проанализировать план запросов и при необходимости скорректировать проектную логику.
3. Провести анализ состояния индексов и при необходимости выполнить перестроение.

Если проблема носит комплексный характер, проанализируйте работу сервера приложения:

1. Собрать и проанализировать файлы конфигурации, способ развертывания приложения.
2. Проанализировать работу Akka и при необходимости скорректировать настройки.
3. Проанализировать работу Quartz и при необходимости скорректировать настройки.
4. Проанализировать конфигурацию веб-сервера (IIS/Kestrel) и при необходимости скорректировать настройки. При анализе конфигурации веб-сервера в первую очередь стоит обращать внимание на параметры, которые указываются в инструкциях по развертыванию BPMSoft.

Информация для обращения в техническую поддержку

Если самостоятельная диагностика не позволила устранить проблему, пожалуйста, соберите следующую информацию и обратитесь в техническую поддержку BPMSoft:

1. Версия и сборка приложения BPMSoft — эта информация требуется для проверки гипотез на инфраструктуре, приближенной к вашей, а также анализа решенных проблем при выпуске новых версий BPMSoft.
2. Подробное пошаговое описание действий, приводящих к возникновению проблемы — подробная информация о проблеме ускоряет анализ и решение.
3. Временной интервал и условия возникновения проблемы — эта информация необходима для максимально точного исследования причин возникновения проблемы.
4. Версия операционной системы, используемой в работе — эта информация требуется для проверки гипотез, связанных со спецификой используемой операционной системы.
5. Конфигурационные файлы приложения — эта информация требуется для анализа режимов работы BPMSoft.
6. Полные логи работы приложения за период воспроизведения проблемы — эта информация необходима для исследования проблем и причин ее возникновения.
7. Инфраструктурные параметры сервера приложения, сервера базы данных, сервера кэширования (количество нод, CPU, RAM, наличие прокси или балансировщика) — эта информация требуется для проверки гипотез на инфраструктуре, приближенной к вашей.
8. Если проблема связана с клиентской частью приложения — HAR-файл, полученный при воспроизведении проблемы, и скриншоты консоли браузера.
9. Результаты предварительного анализа влияния проектного слоя — эта информация способствует ускоренному решению обращения за счет минимизации количества проверяемых гипотез.

Рекомендуем изучить

Системные требования BPMSoft
Мониторинг пула подключений и долгих транзакций