В процессе администрирования крупных информационных баз 1С:Предприятие на платформе 8.3 (особенно при работе в связке с СУБД PostgreSQL) технические специалисты часто сталкиваются со странным поведением системы: один и тот же документ (например, Списание безналичных денежных средств в конфигурации Комплексная автоматизация 2 или ERP) под одним пользователем проводится мгновенно за 5–6 секунд, а под другим — зависает на несколько минут. При этом нагрузка на сервере СУБД возрастает, а процесс PostgreSQL загружает одно из ядер процессора под завязку.
В этой статье мы подробно проанализируем эту проблему, выясним внутренние механизмы платформы 1С и СУБД PostgreSQL, приводящие к подобным «затыкам», и разберем по шагам методы диагностики и системного решения данной проблемы.
Первое, что приходит в голову любому администратору или разработчику при возникновении разницы в скорости работы под разными пользователями, — это ограничение доступа на уровне записей (RLS — Record Level Security). Действительно, наложение тяжелых шаблонов RLS при выполнении запросов на уровне СУБД способно замедлить выполнение операций в десятки раз. Однако, если механизм RLS в базе данных полностью отключен, а разница в производительности сохраняется, необходимо копать глубже.
Проанализируем ключевые симптомы проблемы, описанные в практическом кейсе:
postgres, обслуживающий данную сессию, загружает ровно одно ядро процессора на 100% (на 4-ядерном сервере общая загрузка выглядит как 25%). Это указывает на выполнение тяжелого однопоточного запроса..1CD) в клиент-серверный вариант работы.Причиной такого поведения является механизм сохранения индивидуальных настроек пользователей платформы 1С в СУБД в сочетании с неоптимальными лимитами выделения памяти в конфигурации PostgreSQL.
Платформа 1С:Предприятие сохраняет все персональные настройки пользователей (размеры и положение окон, состав и порядок колонок в динамических списках, быстрые отборы, параметры печати документов, историю выбора и сохраненные варианты отчетов) в специальной системной таблице базы данных. В терминах СУБД эта таблица обычно называется _systemsettings и напрямую связана с системным объектом платформы ХранилищеСистемныхНастроек.
Рассмотрим детально, как эти данные обрабатываются на физическом уровне:
bytea, а сами данные большого объема выносятся в специальную область — TOAST-таблицы.UPDATE или DELETE/INSERT к таблице настроек. Из-за особенностей механизма многоверсионности (MVCC) в PostgreSQL старые версии строк не удаляются физически, а остаются в таблице в виде «мертвых дублей» (dead tuples) до тех пор, пока не отработает очистка.Когда такой пользователь пытается провести документ, система выполняет не только транзакцию проведения, но и обращается к связанным динамическим спискам (журналам документов) для их обновления. В этот момент СУБД PostgreSQL вынуждена сканировать огромную раздутую таблицу настроек интерфейса для этого пользователя, тратя колоссальные ресурсы процессора на чтение, распаковку TOAST-данных и фильтрацию «мертвых» строк.
Ограничение объема памяти процесса PostgreSQL на уровне ~200 МБ при 100% нагрузке на процессорное ядро — это прямое следствие неверной настройки лимитов в конфигурационном файле postgresql.conf.
За распределение памяти под выполнение сложных запросов (сортировки, группировки, хэш-соединения) отвечает параметр work_mem. Если этот параметр оставлен в дефолтном значении (например, 4 МБ или 64 МБ), СУБД выделяет этот небольшой объем под операцию. Если объем обрабатываемых данных (в нашем случае — массив системных настроек пользователя и метаданных динамических списков) превышает этот лимит, PostgreSQL моментально переходит к созданию временных файлов на диске (temp files) и начинает выполнять операции сортировки в дисковой подсистеме.
Процесс СУБД перестает запрашивать оперативную память у операционной системы, визуально «зависая» на объеме около 200 МБ, а вся работа перекладывается на медленный диск, усугубляя время выполнения операции до нескольких минут.
---
Для оперативного устранения проблемы у конкретного «зависающего» пользователя необходимо уменьшить объем сохраненных данных в таблице настроек. Рассмотрим, как это сделать штатными средствами управляемого приложения.
Перейдем в раздел Администрирование — Настройки пользователей и прав — Персональные настройки пользователей (в разных конфигурациях путь может незначительно отличаться, но суть остается прежней — нам нужен инструмент управления настройками).
Выполним очистку по следующему алгоритму:
Если требуется очистить настройки программно для группы пользователей, мы можем воспользоваться встроенным языком 1С. Рассмотрим пример кода для удаления настроек внешнего вида окон программным путем:
// Выбираем конкретного пользователя информационной базы
ИмяПользователя = "ИвановИИ";
ПользовательИБ = ПользователиИнформационнойБазы.НайтиПоИмени(ИмяПользователя);
Если ПользовательИБ <> Неопределено Тогда
// Очищаем настройки внешнего вида форм через системное хранилище
ХранилищеСистемныхНастроек.Удалить(
"Общее/НастройкиВнешнегоВидаФорм",
Неопределено,
ПользовательИБ.Имя
);
ЗаписьЖурналаРегистрации("ОчисткаНастроек",
УровеньЖурналаРегистрации.Информация, , ,
"Успешно очищены настройки для пользователя: " + ИмяПользователя);
КонецЕсли;
После удаления избыточных настроек (как показала практика автора темы, сокращение количества настроек с 210 до 154 полностью возвращает скорость проведения документа к штатным 5–6 секундам) СУБД перестает тратить время на чтение гигантских объемов бинарных данных при каждом действии пользователя.
---
Очистка настроек в 1С — это эффективная, но временная мера. Пользователи со временем гарантированно накопят новые настройки интерфейса, и база данных снова начнет тормозить. Чтобы решить проблему глобально, проанализируем и отредактируем конфигурационный файл СУБД postgresql.conf.
Выполним оптимизацию ключевых параметров выделения памяти:
work_mem):
Установим значение в диапазоне от 64MB до 256MB. Это позволит процессу СУБД обрабатывать даже сложные и объемные выборки настроек пользователей и метаданных динамических списков целиком в оперативной памяти, полностью исключив обращение к медленным временным файлам на диске.
Пример настройки:
work_mem = 128MB
temp_buffers):
Задает максимальный объем памяти для временных таблиц, активно используемых платформой 1С при проведении документов и формировании отчетов.
Пример настройки:
temp_buffers = 64MB
shared_buffers):
Этот параметр определяет объем ОЗУ, используемый PostgreSQL для совместного кэширования данных. Для серверов, выделенных под 1С, рекомендуется выделять под этот параметр около 25% от общего объема оперативной памяти сервера.
Например, для сервера с 64 ГБ ОЗУ:
shared_buffers = 16GB
После изменения параметров памяти обязательно выполним перезапуск службы PostgreSQL для применения настроек.
---
Поскольку таблица системных настроек 1С подвергается постоянным изменениям, критически важно настроить автоматическую очистку «мертвых» строк в PostgreSQL, чтобы не допускать физического раздувания файлов базы данных.
Проанализируем и внесем изменения в параметры механизма Autovacuum в файле postgresql.conf:
# Включаем автоматическую очистку
autovacuum = on
# Количество одновременно работающих процессов очистки (по умолчанию 3, увеличим для нагруженных баз)
autovacuum_max_workers = 4
# Время сна между запусками проверки таблиц (уменьшаем до 10-20 секунд)
autovacuum_naptime = 20s
# Порог запуска очистки при изменении строк (установим 5% вместо дефолтных 20%)
autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.05
Такая агрессивная настройка заставит PostgreSQL своевременно выявлять изменения в таблицах настроек пользователей и оперативно зачищать «мертвые кортежи», предотвращая деградацию скорости поиска записей.
Дополнительно рекомендуется настроить регулярное ночное регламентное обслуживание базы данных СУБД. В состав регламентных процедур необходимо включить выполнение следующих SQL-команд:
VACUUM FULL ANALYZE; физически освобождает место на диске, перестраивая таблицы без накопившегося «мусора». Рекомендуется выполнять ее еженедельно в период наименьшей активности пользователей.
REINDEX DATABASE имя_вашей_базы; восстанавливает структуру индексов, что значительно ускоряет поиск системных настроек конкретного пользователя при авторизации и открытии форм.
Если в вашей системе 1С один из пользователей жалуется на критическое замедление проведения документов или открытия журналов, не спешите переписывать код проведения или искать ошибки в правах доступа. Разберитесь с накопленным кэшем настроек интерфейса данного сотрудника, выполните его выборочную очистку через стандартные механизмы 1С и обязательно проведите ревизию параметров выделения памяти work_mem на стороне PostgreSQL. Комплексный подход позволит навсегда избавить базу данных от подобных избирательных зависаний.