← На главную

Проанализируем ситуацию, с которой часто сталкиваются разработчики и администраторы 1С при попытке задействовать новый функционал расширений: при изменении или полном отключении режима совместимости в конфигурации «Зарплата и управление персоналом» (ЗУП 3.1) сервер 1С Предприятие начинает циклически зависать. В результате рабочий процесс rphost потребляет всю оперативную память, а пользователи не могут подключиться ни к тестовой, ни к рабочей базе на этом же кластере.

Выясним причины нестабильной работы

Разберем основные факторы, приводящие к блокировке и падению кластера серверов 1С при снятии режима совместимости:

1. Ошибки платформы 8.3.11: Релизы линейки 8.3.11 (включая сборку 8.3.11.2867) известны нестабильной работой рабочих процессов, повышенной склонностью к утечкам памяти и критическим сбоям при реструктуризации данных. При попытке применить масштабные изменения структуры таблиц сервер вылетает без явных сообщений об ошибках.
2. Зависание реструктуризации и полнотекстового поиска: Отключение режима совместимости меняет физическую структуру таблиц СУБД. Если в базе задействован механизм полнотекстового поиска (ППД), фоновый процесс индексации может зациклиться, блокируя таблицы базы и забивая ресурсы сервера.
3. Конфликты с подсоединенными расширениями: Если в информационной базе активны расширения, созданные под старый режим совместимости, отмена совместимости в основной конфигурации вызывает критические ошибки инициализации сеансов и совпадение системных имен или команд.
4. Влияние на соседние базы одного кластера: По умолчанию все базы на одном сервере делят между собой рабочие процессы rphost. Когда тестовая база выбывает из строя из-за утечки памяти при реструктуризации, падает весь процесс, утягивая за собой подключения к рабочей базе.

Варианты решения проблемы

Рассмотрим подробнее доступные способы устранения этой проблемы — от безопасной настройки платформы до альтернативных архитектурных решений.

Способ 1. Изменение версии платформы 1С

Так как ключевым виновником сбоев является нестабильная сборка платформы 8.3.11, проанализируем варианты смены релиза:

1. Откат на стабильную ветку 8.3.10: По свидетельству многих специалистов, релизы линейки 8.3.10 (например, 8.3.10.2699) работают корректно и без произвольных падений при снятом режиме совместимости.
2. Переход на более свежие релизы: Если необходимы возможности новых платформ, следует обновиться с проблемной 8.3.11 на проверенные сборки 8.3.12 или выше, предварительно ознакомившись с требованиями текущего релиза ЗУП 3.1.

Способ 2. Правильный порядок отключения совместимости и реструктуризации

Разберем по шагам регламент действий, который минимизирует риски падения базы данных:

1. Сделайте полную резервную копию базы данных.
2. Полностью отключите или удалите все подключенные расширения конфигурации через режим Конфигуратор или раздел Администрирование -> Печатные формы, отчеты и обработки -> Расширения.
3. Зайдите в настройки программы по пути Администрирование -> Настройки программы -> Общие настройки -> Поиск данных и нажмите Очистить индекс.
4. В Конфигураторе измените значение свойства Режим совместимости на Не использовать.
5. Запустите процедуру Тестирование и исправление с обязательным включением флажка Реструктуризация таблиц информационной базы.
6. После завершения реструктуризации выполните операцию Обновить индекс для полнотекстового поиска.
7. Поочередно подключайте и адаптируйте расширения, проверяя, чтобы режим совместимости самого расширения не превышал режим основной конфигурации.

Способ 3. Использование встроенных механизмов вместо снятия совместимости

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

Этот подход позволяет добавлять необходимые пользовательские поля и аналитические разрезы в документы и справочники ЗУП 3.1 без правки конфигуратора, создания новых объектов и риска уронить сервер 1С.

Способ 4. Защита рабочей базы и изоляция тестового контура

Чтобы экспериментальные действия с тестовой базой не мешали работе пользователей в основной базе, выполним настройку кластера серверов:

1. Разворачивайте тестовую базу на отдельном рабочем сервере или на отдельном порту кластера (например, 1641 вместо 1541). Это полностью изолирует процессы rphost.
2. В консоли администрирования кластера серверов 1С настройте ограничения: задайте параметр Предельный объем выделенной памяти и включите регулярный перезапуск рабочих процессов при превышении допустимого размера памяти.