← На главную

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

Проблема разрастания таблицы dbo.BinaryData

Одной из наиболее критических особенностей ветки 8.3.27 (начиная с релиза 8.3.27.1688) стало изменение механизма работы с двоичными данными. Многие администраторы заметили аномальный рост размера базы данных на SQL-сервере. Выясним причину: это связано с тем, что платформа начала активнее использовать таблицу dbo.BinaryData для кэширования сеансовых данных и временных объектов непосредственно в СУБД, вместо использования файлового кэша на стороне сервера приложений.

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

• Мониторинг очистки сеансов: Проверим настройки регламентных заданий по очистке ненужных данных. Платформа должна автоматически удалять устаревшие записи, но при аварийном завершении сеансов или утечках памяти этот процесс может давать сбой — для контроля стабильности пригодится мониторинг ошибок и отправка уведомлений в Telegram.
• Настройка СУБД: Если рост становится критическим, стоит рассмотреть переход на более свежие релизы (например, выше 8.3.27.1964), где разработчики внесли правки в алгоритмы кэширования.

Утечки памяти в рабочих процессах rphost

Следующая серьезная проблема — агрессивное потребление оперативной памяти процессом rphost. Пользователи отмечают, что на версиях 8.3.27.1786 и 8.3.27.1859 сервер может «съедать» до 99% доступной ОЗУ независимо от общего объема памяти на борту. Это часто приводит к ошибке «Свободный рабочий процесс сервера 1С не найден», решить которую поможет автоматическое отключение задублированных сеансов — для этого есть управление сеансами пользователей для оптимизации памяти.

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

1. Откроем консоль администрирования кластера серверов 1С — в этом поможет обработка администрирования кластера и управления сеансами.
2. В свойствах рабочего сервера установим параметр «Безопасный расход памяти за один вызов». Это позволит серверу прерывать выполнение слишком «тяжелых» запросов, не обрушивая весь процесс.
3. Настроим принудительный перезапуск рабочих процессов. Установим параметр «Выключать через» (например, 86400 секунд для перезапуска раз в сутки) или настроим лимит памяти, при достижении которого процесс будет заменяться новым.
4. Проанализируем использование фоновых заданий. В новых версиях БП и ERP часто по умолчанию включены сервисы распознавания текста и интеграции, которые создают высокую нагрузку, что поможет выявить монитор кластеров серверов.

Критические ошибки при динамическом обновлении

Механизм динамического обновления (так называемое «демоническое» обновление) в ветке 8.3.27 стал источником повышенной опасности. Рассмотрим примеры: часто после обновления конфигурации «на лету» Конфигуратор схлопывается, а пользователи начинают получать ошибки при попытке входа. В модуле backend.dll возникает исключение 0xc0000005, что указывает на нарушение прав доступа к памяти из-за поврежденного кэша метаданных.

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

Если же база уже «зависла» в промежуточном состоянии после неудачного обновления, можно применить классический метод очистки таблиц конфигурации в SQL. Для этого (предварительно сделав бэкап!) используются команды очистки таблиц ConfigSave и сброса флага обновления. Однако в версии 8.3.27 структура кэша усложнилась, поэтому лучшим решением будет восстановление из последней корректной копии.

Переход на новую нумерацию: платформа 8.5

Важно понимать стратегию фирмы «1С» относительно нумерации. Версия 8.5.1 является прямым преемником 8.3.27. Она включает в себя все возможности 27-й ветки и внедряет новый интерфейс. Выясним причину этого перехода: разработчики выделяют 8.5 как основную ветку для развития функционала, тогда как 8.3.27 будет получать преимущественно исправления ошибок.

Если ваша конфигурация требует версию не ниже 8.3.27.1688, переход на 8.5.1 может быть оправдан, так как в ней исправлены некоторые критические баги ранних сборок 27-й ветки. Однако будьте готовы к тому, что системные требования к ресурсам сервера у 8.5 выше.

Ошибки при реструктуризации и работе с SQL

Рассмотрим техническую ошибку, часто возникающую на платформе 8.3.27.1688 при работе с тяжелыми базами (УПП, ERP): DataExchangeTcpClientImpl.cpp line=1675. Это свидетельствует о разрыве соединения между клиентом и сервером при длительных операциях реструктуризации. Для решения этой проблемы рекомендуется:

• Увеличить таймауты в настройках SQL-сервера и в строке подключения.
• Проверить сетевые настройки (MTU, настройки сетевых карт на сервере), так как новая платформа более чувствительна к качеству канала передачи данных между сервером приложений и СУБД.

Итоговые рекомендации по выбору версии

Проанализировав опыт сообщества, можно составить следующий алгоритм выбора:

1. Если конфигурация (например, старая УТ 10.3 или самописная база) позволяет использовать режим совместимости ниже 8.3.24, оставайтесь на стабильных релизах ветки 8.3.24.
2. Для современных релизов Бухгалтерии предприятия и ERP, требующих 8.3.27, выбирайте сборки не ниже 8.3.27.1964. Релиз 1936 в профессиональной среде считается проблемным из-за частых вылетов backend.dll.
3. При использовании Citrix или терминальных серверов обязательно отключайте аппаратное ускорение графики в настройках 1С, чтобы избежать «замираний» интерфейса.
4. Всегда устанавливайте платформу с использованием «заглушек» (если это требуется политикой лицензирования вашей организации), но помните, что новые версии платформы имеют усиленную защиту и механизмы проверки лицензионной чистоты, которые могут вызывать ложные срабатывания и блокировку сеансов.

Таким образом, переход на 8.3.27 или 8.5 требует тщательного тестирования на копии базы, настройки лимитов памяти в кластере и полного отказа от небезопасных методов обновления. Только системный подход к администрированию позволит избежать простоев в работе пользователей.