Содержание:

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

Например, для MSSQL сервер - SQLServerProfiler, ExtendedEvents. Они имеют широкий набор метрики и функционал для группировки, агрегирования, сохранения в промежуточные таблицы и т.д. Но что делать, если информационная система 1С работает на платформе PostgreSQL? Для решения этой задачи существует метод, который и будет описан в данной статье.

Конечно же, если есть возможность установить такой популярный инструмент, как Центр управления производительностью (ЦУП), то расследовать неоптимальные запросы можно и его помощью. Это достаточно удобный и интуитивно понятный инструмент. Но очень часто, особенно в небольших организациях нет возможности использовать ЦУП, поэтому приходится использовать штатные средства платформы 1С и СУБД.

Операцию оптимизации запросов можно разделить на четыре основные задачи:

·         Определить список «тяжелых» запросов

·         Установить их место вызова в конфигурации 1С

·         Получить их планы выполнения и метрику на стороне СУБД

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

1.      1С сервер postgresql. Собираем информацию о длительных запросах

На этом этапе нужно собрать sql тексты длительных запросов и информацию об их расположении в конфигурации 1С. Для начала необходимо настроить технологический журнал для получения длительных запросов. Длительность, начиная с которой запрос можно считать потенциально неоптимальным, регулируется свойством Durationus. Это свойство измеряется в микросекундах и подбирается интуитивным способом. В журнале нам понадобятся: текст запроса на языке запросов SQL (свойство Sql) и контекст вызова этого запроса на встроенном языке 1С (свойство Context), чтобы в дальнейшем найти этот запрос в модуле конфигурации базы данных.

Создаем файл logcfg.xml и помещаем его в папку conf каталога конфигурационных файлов системы «1С:Предприятие»

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

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

Запись в логах ТЖ найдена, найден текст запроса в конфигурации.

Переходим к получению планов и метрики на стороне СУБД PostgreSQL. 

2.      Как сделать трассировку postgresql запросов. Создаем файл запросов для трассировки

Создаем в текстовом редакторе файл с расширением .sql

В этот файл необходимо будет скопировать тексты запросов на языке запросов Sql. Но перед этим в самое начало файла необходимо записать команды установки параметров, которые система выполняет при старте сервера. Эти параметры нужны для того, чтобы показатели трассировки соответствовали реальным условиям работы СУБД.

Команды можно скопировать из лог-файлов, расположенных в папке pg_log каталога кластера PostgreSQL. Для того чтобы они залогировались, потребуется в конфигурационном файле postgresql.conf установить параметр log_statement = 'all'

Ниже приведен пример такого лога.

Нужные записи можно найти по ключевым словам statement:SET

Теперь можно вставлять запросы. Перед каждым запросом необходимо установить команду EXPLAIN ANALYZE, а после каждого запроса знак;

EXPLAIN – получаем план запроса, ANALYZE – получаем актуальную статистику для плана

Файл готов… Теперь необходимо выполнить трассировку с помощью командной строки.

Запускаем консоль командной строки в директории PostgreSQL

Командная строка имеет следующий шаблон

psql -U [имя пользователя] -h [имя сервера] -d [имя базы] -f [путь к исходномуфайлу запросов] -o [путь к файлу трассировки]

Для продолжения выполнения потребуется ввести пароль пользователя 

3.      Анализируем трассировку postgresql запросов

Итоговый файл трассировки postgresql запросов имеет следующий вид

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

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

Основные показатели:

·         actualtime – фактическое время выполнения в миллисекундах первой .. последней строки

·         rows – количество обработанных строк

·         loops – количество выполнений операции

Итоговый показатель Executiontime, показывающий не только общую длительность запроса, но и позволяющий оценить насколько эффективно стал работать запрос после оптимизации запросов. После устранения причин неоптимальности на стороне 1С исходный файл запросов можно дополнить оптимизированными текстами. А после сравнить значения Executiontime «старого» текста с «новым».

Для анализа плана запроса можно воспользоваться ресурсом 

Результат разборки плана данным ресурсом на скриншотах:

Операторы плана запроса на которые следует обратить внимание:

SeqScan – последовательное сканирование таблицы. Индекс не используется.

BitmapIndexScan, BitmapHeapScan – чтение большого количества строк. Возможно комбинирование индексов.

IndexScan – поиск в индексе. Может использоваться в ситуации с «не покрывающим» индексом, когда за частью данных приходиться обращаться в таблицу. Если индекс сделать «покрывающим», то оператор может быть заменен на более «скоростной» IndexOnlyScan.

В заключение хочется отметить , что поиск длительных postgresql запросов можно выполнять и без использования технологического журнала. Например, настроить параметры log duration = onиlog_min_duration_statement = [время в миллисекундах] конфигурационного файла Postgre. Тогда в логиpg_log будут попадать и тексты запросов, превышающих по длительности необходимое время. Но в этом случае будет тяжело отыскать точку вызова данного запроса в конфигурации 1С, поэтому в данной статье такой подход я рассматривать не стал.

Специалист компании ООО «Кодерлайн» 

Игорь Торба.