О проекте

Заказчик: крупное промышленное предприятие.

Проблема: системная деградация производительности учетной системы на платформе «1С», работающей на СУБД PostgreSQL.

Ключевые болевые точки:

• Нестабильное время отклика системы в часы пиковой нагрузки, снижение скорости работы пользователей.
• Со стороны ИТ-подрядчика и внутренней команды 1С звучала позиция о «недостаточной производительности СУБД PostgreSQL».
• Существовал риск необоснованной замены СУБД, что повлекло бы за собой дополнительные лицензионные затраты, миграционные риски и простои для заказчика.
• Отсутствовала объективная диагностика: проблема локализовалась «на ощупь», без инструментального анализа взаимодействия приложения и базы данных.

Реализованные работы

Нашей командой проведено комплексное нагрузочное тестирование и аудит связки «1С → PostgreSQL». Работы включали:

1. Глубинный трассировщик запросов

Выполнен анализ очереди запросов на стороне СУБД, захват «сырых» логов и их агрегация.

2. Выявление первопричины

Обнаружено, что бизнес-логика приложения 1С генерирует 20 тысяч последовательных обращений к одной таблице в рамках одной операции. Каждый единичный запрос физически выполнялся за приемлемые 190 мс, однако их каскадный, линейный характер создавал эффект «закрытого шлагбаума».

3. Действия на уровне СУБД

• Проведена низкоуровневая оптимизация: адаптация структуры индексов, настройка параметров кэширования и памяти.
• Результат оптимизации на стороне СУБД: время выполнения единичного запроса снижено с 190 мс до 1,9 мс (ускорение в 100 раз).

4. Анализ прикладного слоя

Подготовлена верхнеуровневая спецификация проблемных мест в логике 1С (избыточные итерации, отсутствие пакетной обработки).

5. Коммуникацию с заказчиком

• Сформирован отчет и презентация для бизнес-заказчика.
• Наглядно продемонстрировано разделение ответственности: СУБД перестала быть «узким горлышком» после наших доработок.

Результат и эффект для организации

Технический результат:

• Скорость выполнения «проблемного» типа запросов улучшена на 2 порядка (с 200 мс до 2 мс).
• Суммарное время выполнения бизнес-операции сокращено с десятков минут до секунд/долей секунд.
• Система перестала упираться в диск и процессор — запас производительности высвобожден.
• Реабилитация PostgreSQL: сняты необоснованные претензии к СУБД. Доказано, что при штатной настройке PostgreSQL обеспечивает производительность, кратко превышающую требования.
• Объективизация диалога: заказчик получил прозрачную картину — «узкое место» находилось на стороне прикладной логики.
• Предотвращение неэффективных затрат: исключена инициатива по замене СУБД, сопряженная с бюджетными расходами и проектными рисками.

Ценность для бизнеса

• Пользователи получили отзывчивую систему.
• ИТ-ландшафт организации сохранил технологическую стабильность.
• Выстроена культура принятия решений на основе фактов, а не субъективных оценок.

Выводы

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

Для заказчика критически важно иметь возможность стабилизировать систему на уровне СУБД без срочного привлечения разработчиков, если это технически возможно. Такой подход позволяет быстрее восстановить работоспособность сервиса и снизить операционные риски. Разработчики в этом случае подключаются позже для устранения первопричины уже в плановом режиме, а не в условиях аварии.

О проекте

Крупная финансовая организация использует PostgreSQL в качестве основной системы управления базами данных для внутренних транзакционных сервисов. База данных обслуживает бизнес-критичные системы, включая обработку финансовых операций и работу внутренних сервисов компании.

Основные характеристики инфраструктуры:

• PostgreSQL production-кластер
• объём основной базы данных — несколько терабайт
• высоконагруженные OLTP-операции
• большое количество параллельных соединений

Система работала стабильно, однако команда эксплуатации начала фиксировать рост нагрузки и решила провести анализ производительности базы данных.

Для диагностики использовался инструмент анализа нагрузки PostgreSQL — PGLens.

Задача

Перед инженерной командой стояли следующие задачи:

• выявить наиболее ресурсоёмкие SQL-запросы
• определить причины роста нагрузки на базу данных
• выявить потенциальные проблемы конфигурации
• подготовить рекомендации по оптимизации PostgreSQL

Основная сложность заключалась в том, что система находилась в production и обслуживала критически важные бизнес-процессы, поэтому анализ необходимо было проводить без влияния на работу сервисов.

Подход

Для анализа нагрузки был использован инструмент PGLens, который собирает и историзирует статистику выполнения SQL-запросов PostgreSQL.

Это позволило:

• определить наиболее ресурсоёмкие запросы
• проанализировать динамику их выполнения
• выявить изменения нагрузки во времени
• определить вклад отдельных запросов в общую производительность системы

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

Анализ

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

Неоптимальные SQL-запросы

Анализ статистики выполнения запросов показал, что часть операций выполняется значительно дольше остальных.

Некоторые из этих запросов:

• выполнялись очень часто
• обрабатывали большие объёмы данных
• имели неэффективные планы выполнения

Именно они создавали значительную часть нагрузки на сервер.

Большое количество соединений

В системе было настроено большое количество одновременных соединений с PostgreSQL.

При отсутствии централизованного пула соединений это приводило к:

• повышенному потреблению памяти
• увеличению нагрузки на планировщик процессов
• снижению общей эффективности работы системы.

Ошибки приложений

Анализ журналов PostgreSQL показал значительное количество ошибок на стороне приложений.

Наиболее распространённые из них:

• нарушения уникальности ключей
• конфликты параллельных транзакций
• ошибки типов данных

Каждая такая ошибка вызывает откат транзакции и создаёт дополнительную нагрузку на систему.

Решение

По результатам анализа были предложены следующие рекомендации:

1. Оптимизация SQL-запросов

Команде разработки были переданы рекомендации по переписыванию наиболее ресурсоёмких запросов.

2. Внедрение connection pooling

Рекомендовано внедрение централизованного пула соединений, например:

• PgBouncer
• Odyssey

Это позволяет существенно снизить нагрузку на PostgreSQL.

3. Анализ ошибок приложений

Команде разработки рекомендовано устранить ошибки, приводящие к откатам транзакций.

4. Оптимизация конфигурации PostgreSQL

Были предложены изменения параметров конфигурации для повышения эффективности работы базы данных.

Результат

Использование PGLens позволило команде эксплуатации:

• выявить наиболее ресурсоёмкие SQL-запросы
• определить основные источники нагрузки на PostgreSQL
• обнаружить ошибки приложений, влияющие на производительность
• сформировать план оптимизации системы

В результате команда получила чёткий план повышения производительности базы данных без риска для production-систем.

Вывод

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

Использование инструментов анализа нагрузки, таких как PGLens, позволяет:

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

Итог

Использование PGLens позволило не только найти тяжёлые запросы, но и привязать рост нагрузки к конкретным релизам приложений и изменениям в паттернах использования базы. На основе полученных данных команда сформировала дорожную карту по оптимизации запросов, конфигурации PostgreSQL и архитектуры подключения приложений, что обеспечило запас по производительности без расширения аппаратных ресурсов.

О проекте

Крупная финансовая организация использует PostgreSQL в качестве основной СУБД для критически важных транзакционных систем. База данных обеспечивает работу внутренних сервисов обработки платежей и финансовых операций. Кластер PostgreSQL обслуживает значительный объём данных и работает в режиме высокой нагрузки.

Основные характеристики инфраструктуры:

• PostgreSQL 11
• сервер: 40 CPU / 256 GB RAM
• объём основной базы данных: более 12 TB
• несколько вспомогательных баз для мониторинга и служебных задач

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

Задача

Клиент обратился с запросом:

• провести аудит состояния PostgreSQL
• оценить корректность конфигурации
• выявить потенциальные проблемы производительности
• предложить рекомендации по оптимизации

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

Ход анализа

В рамках аудита были проанализированы:

• конфигурация PostgreSQL
• журналы ошибок
• статистика нагрузки
• параметры подключения
• структура баз данных
• статистика SQL-запросов

Также был проведён анализ данных системы мониторинга и расширения анализа нагрузки PostgreSQL.

Выявленные проблемы

Устаревшая версия PostgreSQL

Кластер работал на версии PostgreSQL 11, которая уже не является актуальной.

Было рекомендовано плановое обновление до современных версий PostgreSQL (16 или 17), что позволит:

• повысить производительность
• получить улучшения планировщика запросов
• снизить нагрузку на систему хранения

Большое количество ошибок приложений

Анализ журналов показал значительное количество ошибок, возникающих на стороне приложений.

Наиболее распространённые из них:

• нарушение уникальности ключей
• ошибки типов данных
• конфликты параллельных транзакций

Такие ошибки приводят к:

• откату транзакций
• дополнительной записи в журналы
• росту нагрузки на CPU и I/O

Отсутствие централизованного пула соединений

В системе было настроено более 1300 одновременных соединений с PostgreSQL.

При этом централизованный connection pool не использовался.

Это увеличивает:

• нагрузку на планировщик
• потребление памяти
• время переключения контекста процессов

Было рекомендовано внедрение пула соединений (например PgBouncer или Odyssey) для оптимизации управления подключениями.

Нагрузка от систем мониторинга

Анализ показал, что один из сервисов мониторинга генерирует большое количество ошибок, что может негативно влиять на производительность базы данных. Рекомендовано провести диагностику работы этого сервиса и оптимизировать его взаимодействие с PostgreSQL.

Конфигурационные особенности

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

Например, использование режима

wal_level = logical

в случаях, когда логическая репликация не используется.

Неоптимальные SQL-запросы

В ходе анализа статистики запросов были выявлены операции с повышенной стоимостью выполнения. Команде разработки были переданы рекомендации по их оптимизации.

Результаты аудита

По итогам проведённого анализа клиент получил:

• рекомендации по обновлению PostgreSQL
• рекомендации по оптимизации конфигурации
• список проблемных SQL-запросов
• рекомендации по внедрению connection pooling
• анализ ошибок приложений, влияющих на производительность
• рекомендации по оптимизации мониторинга

Это позволило команде эксплуатации сформировать план дальнейшей модернизации инфраструктуры.

Итог

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

Даже при стабильной работе системы анализ конфигурации, журналов ошибок и статистики запросов помогает:

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