← На главную

В процессе работы с базами 1С, работающими на СУБД PostgreSQL, пользователи и администраторы иногда сталкиваются с критической ошибкой: ERROR: out of shared memory (для глубокой диагностики пригодится перенос логов технологического журнала в ClickHouse). Сопровождается она подсказкой HINT: You might need to increase max_locks_per_transaction. Давайте разберем, почему она возникает и как пошагово решить эту задачу, обеспечив стабильную работу обменов данными.

Понимание природы ошибки

Данная ошибка означает, что сервер баз данных исчерпал выделенную оперативную память, отведенную под отслеживание блокировок объектов. В 1С это часто происходит при выполнении операций, которые затрагивают огромное количество записей в рамках одной транзакции — например, при выгрузке документов в JSON, загрузке больших файлов обмена в РИБ (распределенную информационную базу) или выполнении массовых обработок документов.

Когда 1С инициирует транзакцию, PostgreSQL должен зафиксировать блокировки на всех объектах, задействованных в этой операции. Если объектов слишком много, лимит памяти, заданный параметром max_locks_per_transaction, оказывается превышен.

Шаг 1: Изменение конфигурационного файла PostgreSQL

Самый прямой способ решения проблемы — увеличить лимит блокировок. Рассмотрим, как это сделать правильно:

1. Остановите службу сервера PostgreSQL, чтобы изменения вступили в силу безопасно.
2. Перейдите в директорию, где установлена СУБД. Найдите папку data, а внутри неё файл конфигурации postgresql.conf.
3. Откройте этот файл с помощью любого текстового редактора (например, Блокнот или Notepad++).
4. Найдите параметр max_locks_per_transaction. Если он уже задан, измените его значение. Если строки нет, добавьте её в конец файла.
5. Рекомендуется начать с увеличения значения до 250-500. Например: max_locks_per_transaction = 250
6. Сохраните файл и снова запустите службу PostgreSQL.

Важное примечание: увеличение этого параметра потребляет больше оперативной памяти сервера. Это безопасная операция, которая не требует восстановления из бэкапа, однако бесконечно увеличивать лимит не стоит — ресурсы сервера ограничены.

Шаг 2: Анализ архитектуры обмена

Если после увеличения параметра ошибка продолжает возникать, это свидетельствует о том, что архитектура обмена данными в вашей конфигурации требует оптимизации. Рассмотрим, почему это происходит и как проанализировать ситуацию:

• Разбиение транзакций: Если загрузка данных происходит «одним махом», это создает колоссальную нагрузку на таблицу блокировок. Попробуйте модифицировать код 1С так, чтобы запись данных происходила порциями (например, по 500-1000 записей за один раз с явным вызовом ЗафиксироватьТранзакцию()).
• Анализ планов обмена: Проверьте, нет ли в системе избыточного количества зарегистрированных изменений. Переполненные планы обмена заставляют систему блокировать избыточное число объектов.
• Индексация и запросы: Убедитесь, что запросы при обмене работают оптимально. Если запрос выполняется медленно из-за отсутствия нужных индексов в PostgreSQL, транзакция удерживается дольше положенного, быстрее занимая память.

Почему файловая база справляется, а SQL — нет?

Вы могли заметить, что при загрузке того же файла в файловую версию базы 1С ошибка не возникает. Это связано с архитектурными различиями: файловая база управляет блокировками иначе, в то время как PostgreSQL — это мощная серверная СУБД, которая строго следит за целостностью данных и жестко ограничивает потребление памяти согласно вашим настройкам. Появление ошибки в SQL-версии — это сигнал того, что система пытается защитить себя от перегрузки.

Заключение и рекомендации

Увеличение max_locks_per_transaction — это стандартная терапевтическая мера. Если же вы столкнулись с тем, что даже значения 500 или 1000 недостаточно, не продолжайте просто увеличивать число. Вместо этого сфокусируйтесь на оптимизации кода обмена в 1С. Помните, что грамотное разбиение транзакций — это лучший способ сделать работу базы стабильной и быстрой в долгосрочной перспективе.