При переходе с MS SQL на PostgreSQL многие администраторы и разработчики 1С сталкиваются с вопросами производительности. Привычные инструменты, такие как "Центр управления производительностью" для MS SQL, отсутствуют, и возникает закономерный вопрос: какие есть аналоги и методики для анализа и мониторинга длительных запросов 1С в среде PostgreSQL на Linux? Рассматривая концепцию защищенной IT-инфраструктуры на базе Astra Linux, давайте разберем этот вопрос подробно и рассмотрим весь спектр доступных решений — от специализированных платных продуктов до встроенных возможностей самой СУБД.
Для комплексного анализа производительности существуют готовые решения, которые позволяют в реальном времени отслеживать состояние СУБД, находить узкие места и собирать детальную статистику. Для замера производительности контура и поиска узких мест существуют различные подходы, включая сбор технологического журнала.
Это официальное решение от фирмы "1С", предназначенное для глубокого анализа производительности всей системы, включая сервер СУБД. КИП позволяет собирать и анализировать счетчики производительности PostgreSQL, контролировать настройки сервера и сопоставлять нагрузку на СУБД с конкретными действиями пользователей и фоновыми заданиями в 1С. Это мощный инструмент для корпоративного сегмента.
Компания Postgres Pro, разработчик специализированных сборок PostgreSQL, предлагает собственную систему мониторинга. Enterprise Manager предоставляет веб-интерфейс для отслеживания ключевых метрик производительности, позволяет создавать кастомные графики для визуализации нагрузки и помогает в диагностике проблем. Это особенно актуально, если вы используете сборку Postgres Pro Enterprise, которая сама по себе содержит множество оптимизаций для 1С.
На рынке существуют и другие инструменты. Например, PerfExpert предлагает расширение SP_TRACE, которое эмулирует функциональность Microsoft SQL Server Profiler. Также можно анализировать SQL-сервер глазами 1С-ника, используя специализированные обработки для мониторинга текущих запросов, ожиданий и конвертации запросов в формат 1С. Metrika42 — еще одна система, которая поддерживает и PostgreSQL, и MS SQL, помогая отслеживать состояние системы и быстро диагностировать конфликты блокировок.
Даже без установки дорогостоящих систем мониторинга, сам PostgreSQL предоставляет мощные инструменты для анализа производительности. Это основной путь для многих администраторов и разработчиков.
Шаг 1. Активация расширения pg_stat_statements
Это, пожалуй, самый важный инструмент для поиска проблемных запросов. Расширение отслеживает статистику выполнения всех SQL-запросов в системе. Чтобы его включить, нужно выполнить два действия:
postgresql.conf добавьте расширение в параметр shared_preload_libraries:
shared_preload_libraries = 'pg_stat_statements'
После изменения файла требуется перезагрузка сервера PostgreSQL.
CREATE EXTENSION pg_stat_statements;
После этого вы сможете делать запросы к представлению pg_stat_statements, чтобы найти самые "тяжелые" запросы. Например, можно найти топ-10 запросов по общему времени выполнения:
SELECT
total_time,
calls,
mean_time,
rows,
query
FROM
pg_stat_statements
ORDER BY
total_time DESC
LIMIT 10;
Этот запрос покажет запросы, которые в сумме создают наибольшую нагрузку на сервер. Анализируя поля total_time (общее время), calls (количество вызовов) и mean_time (среднее время), можно выявить как редкие, но очень долгие запросы, так и частые, но неэффективные.
Шаг 2. Автоматический анализ планов с auto_explain
Чтобы понять, почему запрос выполняется медленно, нужен его план выполнения. Модуль auto_explain позволяет автоматически записывать в лог PostgreSQL планы запросов, которые выполняются дольше указанного времени. Для его настройки добавьте в postgresql.conf следующие строки:
# Также добавляем в shared_preload_libraries
shared_preload_libraries = 'pg_stat_statements, auto_explain'
# Загружаем модуль
session_preload_libraries = 'auto_explain'
# Устанавливаем порог, например, 2 секунды (2000 миллисекунд)
auto_explain.log_min_duration = '2s'
# Включаем логирование
auto_explain.log_analyze = on
auto_explain.log_verbose = on
После перезагрузки сервера в логах PostgreSQL вы начнете видеть подробные планы выполнения для всех запросов, превысивших порог в 2 секунды. Это бесценная информация для дальнейшей оптимизации.
Получив текст и план медленного запроса, необходимо его проанализировать. Текст запроса из логов 1С содержит внутренние имена таблиц (например, _Document234), что неудобно. Можно использовать самописные конвертеры или просто сопоставлять их с объектами конфигурации вручную. Для анализа самого плана есть отличные инструменты.
Визуализация планов
План запроса в текстовом виде бывает сложно читать. Рекомендуем использовать онлайн-визуализаторы, например, explain.tensor.ru. Вы просто копируете план из лога в этот сервис, и он строит наглядную графическую схему, подсвечивая самые затратные операции. Это позволяет быстро выявить узкие места, такие как полное сканирование таблицы (Seq Scan) там, где ожидалось использование индекса (Index Scan). В подобных случаях для исправления ситуации может пригодиться генератор скрипта для индексации таблиц базы данных PostgreSQL.
Типичная проблема 1С на PostgreSQL: подзапросы
Одна из самых частых причин медленной работы запросов 1С на PostgreSQL — неэффективная работа оптимизатора с соединениями, в которых одна из таблиц является подзапросом. Особенно это касается виртуальных таблиц регистров, которые по своей сути являются сложными подзапросами.
Плохой пример (часто генерируется платформой):
ВЫБРАТЬ
Продажи.Номенклатура,
Остатки.КоличествоОстаток
ИЗ
Документ.РеализацияТоваровУслуг.Товары КАК Продажи
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыНаСкладах.Остатки(&Дата, ) КАК Остатки
ПО Продажи.Номенклатура = Остатки.Номенклатура
В этом случае виртуальная таблица РегистрНакопления.ТоварыНаСкладах.Остатки является подзапросом. PostgreSQL может построить неоптимальный план, сначала рассчитав остатки по всей номенклатуре, и только потом соединяя их с таблицей продаж.
Хорошее решение: явные временные таблицы
Чтобы "помочь" оптимизатору, нужно разбить запрос на части, оформив подзапросы в явные временные таблицы. Это заставляет СУБД сначала материализовать результат подзапроса, а затем выполнять соединение, что часто оказывается гораздо эффективнее.
Переписанный пример:
ВЫБРАТЬ
Продажи.Номенклатура,
Продажи.Ссылка
ПОМЕСТИТЬ втТоварыИзДокумента
ИЗ
Документ.РеализацияТоваровУслуг.Товары КАК Продажи
ГДЕ
Продажи.Ссылка = &СсылкаНаДокумент;
ВЫБРАТЬ
втТоварыИзДокумента.Номенклатура,
Остатки.КоличествоОстаток
ИЗ
втТоварыИзДокумента КАК втТоварыИзДокумента
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыНаСкладах.Остатки(
&Дата,
Номенклатура В (ВЫБРАТЬ Номенклатура ИЗ втТоварыИзДокумента)
) КАК Остатки
ПО втТоварыИзДокумента.Номенклатура = Остатки.Номенклатура
Хотя этот совет сложно применить к типовым конфигурациям без их изменения, он является ключевым при разработке собственных отчетов и обработок. Если вы видите, что запрос тормозит из-за соединения с виртуальной таблицей, перенос ее в ВременнуюТаблицу — первое, что стоит попробовать.
Никакая оптимизация запросов не поможет, если сервер СУБД настроен неправильно. Производительность PostgreSQL сильно зависит от параметров в файле postgresql.conf. Для 1С критически важны следующие настройки:
shared_buffers: Основной кэш данных PostgreSQL. Рекомендуемое значение — 25% от доступной оперативной памяти сервера.work_mem: Память, выделяемая на одну операцию сортировки или хэширования внутри запроса. Неправильное значение может приводить к сбросу временных данных на диск, что резко замедляет выполнение. Для сложных отчетов 1С значение может потребоваться увеличить.maintenance_work_mem: Память для служебных операций (создание индексов, очистка). Увеличение этого параметра ускоряет регламентные операции. Для тех, кто предпочитает избегать командной строки, полезным будет решение по обслуживанию баз данных 1C на Postgresql под Astra Linux.random_page_cost: Стоимость чтения случайной страницы с диска. Для современных SSD-дисков этот параметр рекомендуется понижать (например, до 1.1-1.5), чтобы планировщик чаще выбирал сканирование по индексу вместо полного сканирования таблицы.Подводя итог, можно сказать, что для эффективного анализа производительности 1С на PostgreSQL необходим комплексный подход. Начните с настройки встроенных инструментов, таких как pg_stat_statements и auto_explain. Анализируйте планы "тяжелых" запросов с помощью визуализаторов и применяйте практические приемы оптимизации, такие как использование временных таблиц. И не забывайте про базовую настройку самого сервера — это фундамент стабильной и быстрой работы вашей системы.