Технологический журнал 1С для PostgreSQL: настройка без гигабайтов логов

Администратор положил logcfg.xml, подождал минуту и поискал событие DBPostgreSQL. Файлы появились. Нужных записей нет.

Платформа исправна. Ошибка в имени события: PostgreSQL в технологическом журнале называется DBPOSTGRS.

Не включайте весь журнал ради одного медленного документа. На нагруженном сервере он может записывать гигабайты в час. Вам нужен точечный замер: обращения одной базы к PostgreSQL, только медленные запросы. Так Вы увидите, где прошли 40 секунд — внутри СУБД или в коде 1С.

Журнал регистрации здесь не поможет #

Журнал регистрации отвечает на вопрос, что сделал пользователь: изменил справочник, записал документ, запустил отчёт. Технологический журнал показывает, как платформа выполнила это действие: сколько длился SQL-запрос, где возникла блокировка, сколько памяти занял rphost.

Документ провели за 40 секунд. Журнал регистрации подтвердит проведение, но не объяснит задержку. Причину ищите в технологическом журнале.

Если PostgreSQL окажется ни при чём, переходите к параметрам рабочих процессов 1С.

Где платформа ищет logcfg.xml #

Конфигурация технологического журнала лежит в каталоге conf платформы. Практическое руководство OTUS приводит два пути для Windows:

C:\Program Files\1cv8\conf\logcfg.xml
C:\Program Files\1cv8\<версия>\bin\conf\logcfg.xml

Первый файл действует для всех установленных версий платформы. Второй — только для одной, например 8.3.22.1750.

На Linux встречаются три пути:

/opt/1cv8/conf/logcfg.xml
/opt/1cv8/x86_64/<версия>/conf/logcfg.xml
/opt/1cv8/x86_64/current/conf/logcfg.xml

Сначала посмотрите, откуда запущены ragent и rphost. Затем положите файл в каталог conf этой версии. Копировать одну конфигурацию во все найденные каталоги не надо: потом Вы не поймёте, какой файл прочитала платформа.

Службу перезапускать не требуется. По руководству OTUS, платформа сама перечитывает logcfg.xml, обычно в течение минуты. Удалите файл — сбор остановится тоже автоматически.

Минимальная конфигурация для PostgreSQL #

В методике фирмы «1С» по расследованию проблем производительности PostgreSQL событие называется DBPOSTGRS. Регистр и сокращение важны: не DBPostgreSQL, не DBPOSTGRES, а DBPOSTGRS.

Минимальная конфигурация выглядит так:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
 <log location="D:\1C-TechLog" history="24">
 <event>
 <eq property="Name" value="DBPOSTGRS"/>
 </event>
 <property name="all"/>
 </log>
</config>

Атрибут location указывает отдельный каталог для файлов. Не пишите журнал на системный раздел лишь потому, что там установлена платформа. Если каталог разрастётся, вместе с диагностикой встанут Windows и службы 1С.

Параметр history="24" хранит файлы 24 часа. При ротации платформа удаляет старые. Для короткой проверки суток хватает: воспроизвели задержку, забрали журнал, остановили сбор.

Внутри D:\1C-TechLog платформа создаст каталоги процессов: rphost, ragent, rmngr. Часовые файлы получат имена вида ГГММДДЧЧ.log.

Через минуту после сохранения logcfg.xml откройте прежде всего каталог rphost. Именно там будут обращения рабочих процессов к СУБД.

Ограничьте сбор одной базой и медленными запросами #

Конфигурация выше записывает все события DBPOSTGRS со всеми свойствами. Если на сервере несколько баз, Вы получите лишние файлы и потратите больше времени на разбор.

Поле p:processName содержит имя информационной базы. Оператор ge пропускает события, у которых значение свойства не меньше указанного. Длительность хранится в поле Dur и измеряется в микросекундах.

Одна секунда — это 1 000 000 мкс:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
 <log location="D:\1C-TechLog" history="24">
 <event>
 <eq property="Name" value="DBPOSTGRS"/>
 <eq property="p:processName" value="Accounting"/>
 <ge property="Dur" value="1000000"/>
 </event>
 <property name="all"/>
 </log>
</config>

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

Порог 50–100 мс покажет больше деталей, но каталог будет расти быстрее.

По данным руководства OTUS, жёсткие фильтры сокращают объём с гигабайтов в час до десятков мегабайт в день. Это не гарантированный размер. Он зависит от числа сеансов, количества запросов и порога Dur, поэтому следите за свободным местом во время замера.

Элемент <plansql/> добавляет планы SQL-запросов. Методика фирмы «1С» не советует включать его на рабочей системе без отдельного диагностического окна: сбор влияет на производительность.

Сначала найдите медленный запрос через обычный DBPOSTGRS. План снимите отдельно.

Как отделить задержку PostgreSQL от задержки в 1С #

Один долгий DBPOSTGRS не доказывает, что серверу не хватает процессора, памяти или NVMe. Запрос мог прочитать лишние строки из-за плана выполнения. Возможен и другой сценарий: код 1С сотни раз вызывает короткий запрос.

Методика фирмы «1С» предлагает сравнить суммарную длительность DBPOSTGRS со временем серверных вызовов CALL. Проведите второй короткий замер: добавьте событие CALL с тем же фильтром по базе, затем сложите значения Dur из файлов rphost через awk или другой анализатор журнала.

Формула такая:

доля СУБД = сумма Dur для DBPOSTGRS / сумма Dur для CALL

В примере из методики получилось 0,65. Значит, PostgreSQL занял 65% времени серверного вызова.

Если на DBPOSTGRS уходит больше половины длительности CALL — разбирайтесь со скоростью запросов к СУБД. Если меньше, одна эта доля решения не даёт: смотрите и код 1С, и число серверных вызовов, и настройки rphost.

Одна эта доля не обосновывает покупку нового сервера. Она лишь показывает, куда идти дальше.

При доле 65% найдите запрос с максимальным Dur и выполните для него EXPLAIN ANALYZE VERBOSE на стенде либо в согласованное диагностическое окно. PostgreSQL вернёт план и фактическое время каждого его узла.

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

Порядок проверки на сегодня #

Проведите один ограниченный замер:

1. Найдите каталог conf версии платформы, которая запускает кластер.
2. Создайте отдельный каталог для журнала и укажите его в location.
3. Установите history="24".
4. Включите DBPOSTGRS с правильным регистром.
5. Ограничьте события через p:processName и порог Dur.
6. Через минуту проверьте часовой файл в каталоге rphost.
7. Воспроизведите медленную операцию и заберите журнал.
8. Во втором коротком замере добавьте CALL и посчитайте долю DBPOSTGRS/CALL.
9. После сбора данных удалите logcfg.xml.

Доля PostgreSQL больше половины — разбирайте SQL и план выполнения. Меньше — одна эта доля не решает: смотрите и серверные вызовы, и код 1С, и параметры рабочих процессов.

Сначала замер, потом счёт на железо. Иначе можно заменить сервер и оставить причину задержки на месте.