При переводе информационных баз 1С:Предприятие с файлового варианта на клиент-серверный под управлением СУБД PostgreSQL администраторы часто сталкиваются с неожиданными трудностями. Одной из наиболее распространенных проблем является сбой при создании резервных копий (бэкапов) больших баз данных, таких как «1С:Бухгалтерия предприятия 3.0» (БП) или «1С:ERP». Процесс копирования внезапно прерывается, а утилита резервного копирования возвращает ошибку, связанную с нехваткой разделяемой памяти (shared memory) и таблицы блокировок.
В этой статье мы подробно разберем природу данной ошибки, выясним, почему стандартные рекомендации на форумах могут приводить к зависанию всей системы 1С, и рассмотрим пошаговое руководство по правильной настройке PostgreSQL для обеспечения стабильного и быстрого резервного копирования. При обслуживании большого количества систем можно автоматизировать регулярное архивирование и обслуживание нескольких баз 1С, настроив запуск задач по расписанию.
Рассмотрим типичный текст ошибки, возникающий при работе планировщика бэкапов (например, SQLBackupAndFTP или стандартной утилиты pg_dump):
[Error] Failed to backup "BP" database with "Full" backup type: pg_dump.exe process has finished with "1" code. The error message: "pg_dump: error: query failed: ERROR: out of shared memory HINT: You might need to increase max_locks_per_transaction. pg_dump: error: query was: LOCK TABLE public._document12740 IN ACCESS SHARE MODE".
Для того чтобы понять причины происходящего, проанализируем внутренние механизмы СУБД PostgreSQL и платформы 1С:Предприятие:
pg_dump запускает транзакцию с высоким уровнем изоляции. В рамках этой транзакции утилита накладывает блокировку типа ACCESS SHARE на абсолютно все таблицы, представления, индексы, последовательности и системные каталоги, имеющиеся в базе. Это гарантирует, что структура данных не изменится в процессе копирования.Размер таблицы = max_locks_per_transaction * (max_connections + max_prepared_transactions)
pg_dump, превышает емкость этой таблицы, СУБД возвращает ошибку нехватки памяти блокировок (out of shared memory) и предлагает увеличить параметр max_locks_per_transaction.Часто администраторы пытаются увеличить параметр max_locks_per_transaction в конфигурационном файле postgresql.conf до 150, 256 или даже 1000 единиц, однако повторный запуск бэкапа все равно завершается ошибкой. Почему так происходит?
Дело в том, что параметр max_locks_per_transaction относится к категории настроек, требующих обязательного и полного перезапуска службы СУБД PostgreSQL. Обычная команда перечитки конфигурации (команда pg_ctl reload или перезапуск через консоль без реального перезапуска процесса) не приводит к перевыделению сегмента разделяемой памяти. Только после полной остановки и последующего старта службы новые лимиты вступают в силу.
Кроме того, перезапуск службы принудительно разрывает все зависшие сессии пользователей и фоновые задания 1С, которые могли удерживать «зависшие» блокировки в системной таблице, временно облегчая нагрузку на общую память.
Пытаясь решить проблему, администраторы иногда обращаются к автоматическим генераторам настроек PostgreSQL или принимают вредные советы из сети. Рассмотрим пример критически заниженных настроек производительности, из-за которых пользователи начинают жаловаться на жуткие зависания интерфейса 1С:
# Пример ОШИБОЧНОЙ настройки для рабочей базы 1С
shared_buffers = 256MB
work_mem = 16MB
temp_buffers = 32MB
max_locks_per_transaction = 1024
Почему эти параметры (кроме max_locks_per_transaction) губительны для рабочей базы 1С?
Давайте разберем по шагам, как правильно настроить параметры СУБД, чтобы успешно делать резервные копии и при этом гарантировать максимальное быстродействие системы 1С:Предприятие.
Откроем конфигурационный файл postgresql.conf (в Windows он обычно находится в папке C:\Program Files\PostgreSQL\...\data\, в Linux — в каталоге /var/lib/pgpro/data/ или /etc/postgresql/).
Найдем параметр max_locks_per_transaction. Для баз данных 1С (особенно тяжелых конфигураций ERP, КА, БП) его значение по умолчанию (64) является недостаточным. Рекомендуется установить:
max_locks_per_transaction = 512
Для очень крупных баз данных с интенсивным документооборотом и большим числом пользователей можно безопасно установить значение 1024. Каждый элемент таблицы занимает всего около 270 байт в оперативной памяти, поэтому даже значение 1024 при 500 одновременных соединениях займет не более 130 МБ ОЗУ, но полностью ликвидирует ошибку out of shared memory.
Рассчитаем оптимальные параметры производительности СУБД в зависимости от физического объема оперативной памяти (ОЗУ) вашего сервера. Предположим, что под нужды PostgreSQL на сервере выделено 16 ГБ ОЗУ:
shared_buffers = 4GB (для сервера с 16 ГБ ОЗУ)
effective_cache_size = 12GB
work_mem = 64MB
VACUUM). Рекомендуется ставить в районе 10% от ОЗУ.
maintenance_work_mem = 1GB
Для того чтобы все внесенные изменения применились и СУБД корректно выделила новый сегмент разделяемой памяти, выполним принудительный перезапуск службы.
Для ОС Windows:
services.msc и нажмите Enter).postgresql-x64-14 или PostgreSQL Database Server).Для ОС Linux:
Выполним в терминале команду перезапуска от имени суперпользователя:
sudo systemctl restart postgresql
# Или для сборок Postgres Pro:
sudo systemctl restart postgrespro-1c-14
Хотя логический дамп через утилиту pg_dump является популярным средством архивации, по мере роста базы данных до сотен гигабайт этот способ начинает создавать слишком большую нагрузку на дисковую подсистему и процессор, а также накладывает нежелательные транзакционные блокировки. При работе в ОС Linux для автоматизации этого процесса и своевременного удаления устаревших копий удобно использовать готовый инструмент для управления резервным копированием баз 1С.
Проанализируем альтернативные профессиональные методы резервного копирования:
Использование утилиты WAL-G (или аналогичной pgBackRest) является современным стандартом администрирования PostgreSQL, особенно в инфраструктурах с базами данных 1С. Принцип работы заключается в непрерывном архивировании файлов журналов предзаписи (WAL-сегментов) и периодическом снятии базовой резервной копии непосредственно с диска СУБД.
Основные преимущества использования WAL-G:
ACCESS SHARE на таблицы. Вы полностью застрахованы от возникновения ошибки out of shared memory.Выгрузка информационной базы в файл резервной копии .dt выполняется через Конфигуратор 1С или с использованием скриптов администрирования (утилита ibcmd или COM-соединение). Этот метод гарантирует логическую целостность на уровне прикладных объектов платформы. Для упрощения этой процедуры силами обычных пользователей можно использовать обработку для резервного копирования в режиме 1С:Предприятие.
Однако помните о важных ограничениях данного метода:
.dt требует монопольного доступа к базе данных. Вам придется принудительно завершить сеансы всех активных пользователей и заблокировать регламентные задания..dt рекомендуется использовать только для целей разработки, тестирования или переноса баз на другие СУБД, но не для регулярного ночного автоматического резервного копирования.Мы выяснили, что ошибка резервного копирования out of shared memory в связке PostgreSQL и 1С вызвана превышением лимита доступных слотов блокировок из-за обилия таблиц в конфигурациях 1С. Для ее устранения достаточно увеличить параметр max_locks_per_transaction до 512–1024 и выполнить полный перезапуск службы СУБД. При этом важно следить за тем, чтобы системные параметры оперативной памяти (в первую очередь, shared_buffers) оставались на высоком уровне для предотвращения критических зависаний бизнес-приложений.